Writing img files to 360K disks with no other PC

Software related questions

Re: Writing img files to 360K disks with no other PC

Postby Trixter » Sat May 02, 2020 8:00 pm

I recently stumbled on my PCjr cassette cable, and briefly had the same thought. However, trying to write a floppy disk over cassette audio isn't really feasible because there's no way to stop the incoming stream of data and the amount you'd need to make a functional bootable diskette won't fit into the RAM available in a 128K PCjr. And making the user switch cables and host systems during the process seems more cruel than just typing in a 15-line BASIC program :-)
You're all insane and trying to steal my magic bag!
Trixter
 
Posts: 658
Joined: Mon Sep 01, 2008 12:00 am
Location: Illinois, USA

Re: Writing img files to 360K disks with no other PC

Postby MattCarp » Sun May 03, 2020 6:55 am

I stumbled across a USB-floppy adapter on eBay.

This is intended for 3.5" drives, but I think the floppy drive's electrical interface is the same. So, with an adapter for the connectors (or the use of a ribbon cable that has both types of drive connectors), I wonder if it would work.

Has anyone tried / considered this?
MattCarp
 
Posts: 79
Joined: Sun Aug 31, 2008 11:35 am

Re: Writing img files to 360K disks with no other PC

Postby Brutman » Sun May 03, 2020 12:40 pm

I think that the problem you will run into is that those USB adapters will present themselves to the host machine as a 1.44MB block storage device, and if you are lucky they will also support 720KB. So while electrically you can connect anything you want to it, you may not be able to convince the host to write what you want to it or the onboard controller to use the lower data rate required by double density media.

(The format is an issue if the drive presents itself as a block device that only does LBA addressing. Even though a 360 drive has a subset of sectors and tracks, the geometry is different and the LBA translation will be wrong.)
Brutman
Site Admin
 
Posts: 1180
Joined: Sat Jun 21, 2008 5:03 pm

Re: Writing img files to 360K disks with no other PC

Postby bhtooefr » Tue Jun 16, 2020 5:08 am

Might be worth modeling this off of what ADTPro does.

The Apple II benefits from having console redirection in ROM, so there's no actual type-in program - essentially, you redirect I/O to serial, and then the ADTPro server types its stage 1 loader in automatically. That loader then locates the serial hardware in use and loads ProDOS and the ADTPro client. (The old scheme had the server type in ProDOS, launch it, and then had the server type in the ADTPro client. This was... suboptimal for performance, but was effective.)

ADTPro also has an audio loader - essentially you tell it to load ProDOS to a region of memory, run it, load ADTPro to a region of memory, and run it. Once it's running, the feedback mechanism to the host is that two audio cables are connected between the Apple II and the host. First, ADTPro knows how much memory it has to work with, so it's sending chunks of the correct size, and also, the client can signal the host over the tape output connection. (So, you don't need the motor control signals of the PCjr, you can just do it as in-band signalling.)

(The Apple III version of ADTPro does have to have a 77 byte stage 1 loader, which looks like it then sends a stage 2 loader that is similar in function to the current "Speediboot" Apple II loader.)

On a PC, the cassette method would likely be pretty trivial - easiest way would be to just have a BASIC stage 1 loader and use LOAD"CAS1:",R or RUN"CAS1:", and then have that load a stage 2 fastloader (which, given the similarities in cassette format, would look rather similar to an Apple II or ZX Spectrum fastloader, as I understand).

A serial loader would need to be typed in, so you'd definitely want a short type-in stage 1 loader there.
bhtooefr
 
Posts: 5
Joined: Wed Aug 24, 2016 8:32 pm

Re: Writing img files to 360K disks with no other PC

Postby Trixter » Tue Jun 16, 2020 9:12 am

While CAS is the obvious way of reducing type-in, only the original PC and PCjr could do this, and the cables are difficult to find or would have to be made by the end user. Serial cables with USB on one end, however, are plentiful; in addition, they'd work with the 5155, 5160, 5162, 5170, and PS/2 systems, all of which have ROM BASIC but no cassette port. So that's why I was going to target serial at first.

You got me thinking about console redirection, though. If that could be established in ROM BASIC with a smaller type-in than a "grab bytes from serial and poke them into memory" process, that would be a win. However, I haven't looked into how to "stuff" the keyboard; if it can't be done through the BIOS and memory access, it's not worth it (PCjr keyboard handling is way different than all other systems).

I was also going to experiment with defining strings to hold binary, rather than a series of DATA statements. So instead of:

100 DATA 31,37,65,211,63,88

...the binary data can be translated into typable ASCII:

100 PROG$ = "fWnf9JnalpwIU"

That should be less typing, and faster overall.
You're all insane and trying to steal my magic bag!
Trixter
 
Posts: 658
Joined: Mon Sep 01, 2008 12:00 am
Location: Illinois, USA

Re: Writing img files to 360K disks with no other PC

Postby Hargle » Wed Jun 17, 2020 6:19 am

I too was thinking about console redirection via ctty, except you need DOS to get ctty.

I don't quite know what ctty does under the hood but if that functionality could be created in a small type-in BASIC program, then the keyboard could be swapped out for the COM port and then you could push a large, complicated BASIC program in from the remote machine instead of typing the whole thing in by hand.
Hargle
 
Posts: 157
Joined: Wed Apr 27, 2011 3:53 pm

Re: Writing img files to 360K disks with no other PC

Postby Trixter » Wed Jun 17, 2020 12:25 pm

I checked a few "keyboard stuffer" programs earlier in the week, thinking about this, and saw that they all have various methods, from overriding INT9, to *stopping* INT9 and manipulating the keyboard buffer data in the BDA then re-enabling INT9 once that's drained. Ignoring the fact that IBM ROM BIOS make IVT assumptions which could make INT16/INT9 manipulation problematic, none of the methods looked as simple as "read incoming bytes over serial using the BIOS, poke into memory, and JMP". So I'm abandoning the console redirection idea for now.
You're all insane and trying to steal my magic bag!
Trixter
 
Posts: 658
Joined: Mon Sep 01, 2008 12:00 am
Location: Illinois, USA

Previous

Return to PCjr Software

Who is online

Users browsing this forum: No registered users and 3 guests

cron