• Please review our updated Terms and Rules here

ADTPro for PC?

ADTPro for PC?


  • Total voters
    13
I think I'm going to have to patent this one ... A keyboard 'dongle' using pretty much the same code as the AT to XT keyboard scancode converter that has an EPROM with the program stored on it.

  • Power off your PC
  • Insert between keyboard and machine
  • Power on
  • Get to Cassette BASIC
  • Press button
  • Have horribly complicated program 'autotyped' by the microcontroller.
  • Post pictures on SlashDot and become famous.

Still requires the cassette BASIC though ...
You may be hearing from my lawyers; I use something like that in several production systems, although it's a computer uploading the data through an RS-232 > PS/2 kbd converter (Hagstrom KE-24).

You can have the fame, I'll settle for a cut of the profits ;-)
 
Focusing In...

Focusing In...

I've heard alot of good feedback. Initially, I wasn't clear on what the objective is. The objective for me was to be able to hook up my ancient PC, XT, and AT and make disks on it without having accessibility or availability of any intermediary machine with said disk drive in it.

Stepping down is, or will be at some point an issue for people. How do you get software from modern machine to your classic piece? There are many ways as suggested; build a brand new PCB, use XT-IDE, step down media via that intermediary machine, etc., et. al.

Software as difficult as it is to program, in my estimation is the best bet for this goal. I had thought and hoped that having a baseline of a machine with ROM BASIC and a serial port would be less difficult than it is. It would be amazing if you had a machine with nothing to fire up ROM BASIC, type in a few commands and start creating disks but it looks like that is too cost prohibitive for only ROM BASIC machines. With that in mind I will settle on just having an old PC, 360k floppy disk drive and a serial port.

With your help, and the help of an old IBM programmer I know (won't be back until the spring, is in Florida until then) I hope we can get a working prototype going.
 
I understand your requirements, but you seem to be ignoring some of the major roadblocks to a project like this:

  1. The required code is much longer than a few lines. Typing errors and time are going to be a major issue.
  2. Only genuine IBM machines can use this. It's not useful in any way for a clone machine, thus severely limiting the audience.
  3. COM ports are not even standard on old hardware, and may be at different I/O ports.

Can it be done? Sure. It's even pretty easy. Except for the data entry problem.

A usable solution is going to involve cracking the case open and installing something, at least temporarily ...
 
I've changed the scope of the project, it does not require a PC, XT, or AT with ROM BASIC. All it requires now is a computer (IBM or clone) and a serial port. All I'm looking to do now is write disks using the hardware in the system without cracking the case.

Commodore John? I would still be very appreciative of your contributions, especially now since ROM BASIC is not requirement.
 
Clone systems generally do not have a BASIC interpreter on them. If they don't boot from the floppy or a hard drive, they just sit and blink at you. It's not a pretty sight.

So did I miss something? How do you plan to cover these machines?
 
With your revised requirements, it sounds like you'd be best off with a way to move data over the serial port into DOS using the tools that come with a default DOS install. This would be very useful; in fact, I have an application for it immediately -- getting files onto systems like the NEC APC. Another forum member was talking with me about possibly redirecting console output to allow text input through the serial port to be dumped to disk. By using console redirection, you could open an editor and dump text into it by sending a file from your terminal in raw text mode. This is compatible with DOS at least back to 2.11 (the APC's DOS distribution supports it), keeps you fairly high-level, and doesn't require writing a ton of code by hand.

This would still require yout to have a boot disk for your system...but in the case of the APC, I do have a boot disk, just no terminal programs or (currently) a system with 8" drives. You could send a BASIC program (or binary, if you can figure out how to send one through console redirection) to the DOS system this way, and that'd avoid opening the case. If the program was either a disk imaging application, or a serial terminal, you'd then have the ability to move arbitrary data between new systems and old ones.

EDIT: D'oh! Of course! You could use serial console redirection to type ASCII-formatted hex into DEBUG.
 
His requirements are a 'bare metal' install - there is no boot diskette.
 
His requirements are a 'bare metal' install - there is no boot diskette.

Isn't that actually impossible with the new requirements of /any/ IBM-compatible clone? None of my clone machines will do anything without a boot ROM or floppy. If the IBMs with ROM BASIC provided a difficult solution for bare-metal bootstrapping, then surely clone machines with no BASIC or monitor are actually impossible to boot without opening the case.
 
Bingo! We've been trying to point out that the pool of eligible machines for this tool is very very small ... And even with interpreted BASIC in ROM, it requires a lot of error prone typing.
 
New Goals & Requirements

New Goals & Requirements

The intial thought was...

If I have a PC, XT, or an AT and I have disks but no software on them, how could I get the software onto those disks without using an intermediary machine, getting an expansion card or having (the ability) to put a 360k disk drive into a modern computer...​

So then I thought, would it be possible to port ADT Pro to the PC. Thinking very logically, I thought the Apple II has built in ROM BASIC, the IBM PC also has built in ROM BASIC. The Apple II's have serial ports. I had made the (false) assumption that every PC, XT, or AT came with some kind of serial port.​

Everyone chimed in to correct my errors and pointed out that those who only have authentic IBM's with ROM BASIC is a very small subset of the vintage user. Even more so, using only the code that is available in the ROM BASIC makes it virtually impossible to port the functionality of ADT Pro to the IBM PC.​

With all this now being said, I must change the goals and the requirements to make it more valuable as a tool, and easier to build (otherwise it will never be built)...

New Goals
  1. To write disk images to original disk drives without moving or installing hardware

New Requirements
  1. PC that can boot to DOS
  2. Serial Port
  3. Appropriately pinned serial cable
  4. Modern PC for host
  5. Serial Port on Modern PC

I think the software solution with those goals and requirements is much more doable. I've also updated the SourceForge page to reflect those changes. I know that getting one of those pages may seem premature and overkill, but I'm hoping that others who are not citizens of these forums may find it to be a challenge.
 
Ah, yeah, that's what I thought you'd meant with the updated requirements at first. In that case, my idea should work. I won't likely have time to work on it soon, but if no one else jumps on it, I'll /eventually/ get to it. Like I said, it'd be perfect for getting software to my NEC APC. Writing the program that's to be sent from the modern machine using only DOS calls should keep it DOS compatible, and not require the use of IBM compatible hardware, right?
 
New Requirements
  1. PC that can boot to DOS
  2. Serial Port
  3. Appropriately pinned serial cable
  4. Modern PC for host
  5. Serial Port on Modern PC

I think the software solution with those goals and requirements is much more doable. I've also updated the SourceForge page to reflect those changes. I know that getting one of those pages may seem premature and overkill, but I'm hoping that others who are not citizens of these forums may find it to be a challenge.
Ah, well, this is the first time that you've mentioned "can boot DOS"; that does make a difference (assuming you mean "is running DOS" - they *can* all boot dos if there is bootable media available). Your requirements don't include at least one floppy drive?

I'd think that's doable now, depending on which version of DOS you're running and which you want to create:

Inject Laplink or Interlink, copy over a compressed image and the software to uncompress and write the disk, and do the deed.

Am I missing something?

But even reading an image over the com port and writing to disk oughta be pretty trivial. Are we sure that doesn't already exist?

And as Glitch points out, there's DEBUG used with CTTY...
 
Last edited:
... If you can boot DOS, you must have some kind of removable media drive.
Really? I'd heard that you could boot DOS off a hard disk even if you don't have any removable media...

Waaait a minute! I have several system just like that, hard disk and I/O ports only and happily running DOS apps...

;-)
 
the intial thought was...
  • if i have a pc, xt, or an at and i have disks but no software on them, how could i get the software onto those disks without using an intermediary machine, getting an expansion card or having (the ability) to put a 360k disk drive into a modern computer...
  • so then i thought, would it be possible to port adt pro to the pc. Thinking very logically, i thought the apple ii has built in rom basic, the ibm pc also has built in rom basic. The apple ii's have serial ports. I had made the (false) assumption that every pc, xt, or at came with some kind of serial port.

This wasn't a bad idea; I've had the same thought. It's an interesting problem to solve: Given a functional IBM PC/XT/AT and blank media, but no DOS boot disks, can you transfer a disk image to the PC/etc. and create a disk out of it? What could you connect between a modern system and a PC that would work? You're going to need to open up the system and connect something, so here's a list of common (for our hobby) things you could install and connect to a modern system:

  • Serial port (duh)
  • Parallel port
  • Sound card
  • Ethernet
  • Joystick

(did I miss any?) Of the above, only Ethernet would not be practical, as every card is different and a small BASIC program could maybe support only one. A sound card is very easy to connect to a modern system, but would require manual effort, as well as a clever way to transmit the data (I know this is a solved problem for cassettes but I'm not familiar with protocol details). Parallel and Serial are more practical as there are BIOS routines for working with them. The joystick port would be dead simple to support as long as a suitable protocol could be designed for the transfer, although this would require some sort of special cable and host support, making it less practical for the end user.

But what if you have no peripherals at all except the keyboard port? reenigne solved this problem by discovering a factory test protocol in the BIOS that is activated via the keyboard port, and wrote a custom piece of hardware+software to use the keyboard port as a makeshift serial port. This is brilliant, but requires knowledge and skill outside the realm of most people.

I think the original proposal is reasonable. I've always thought that using a sound card would be the way to go, since all you need is anything that can produce sound (you could "play" a disk image using your ipod for example). Initializing a Sound Blaster-compatible sound card and grabbing data from it is easy; writing disk sectors is easy. Only the protocol details elude me; if anyone has some pointers to how this is typically tackled, I'd love to read up on it.

If this can be put into a program that takes a user less than 30 minutes to type, I'd consider that very useful, wouldn't you?

PS: A similar program could be used to output a disk image, to transfer disk data off of a system and make the audio files.
 
I would think this could be done a bit simpler if one worked in stages and kept the connection method simple. Things like parallel, sound input or joystick are pretty complex, so I'd stick to serial.

Step 1) simple dozen line BASIC program to grab and run a small(ish) bootloader over serial

Step 2) that then downloads a larger program to handle remote control of the disk drive over serial

Step 3) reboot so it boots from the floppy as a option.

Doesn't sound too hard... The trick would be to keep it simple. Parallel for bi-directional or even normal download is too complex for something simple in BASIC, much less any more complex hardware given that a ROM BASIC should be more than capable of handling serial.

Code:
10 DIM CODE% (255)
20 FIELD 1, 255 AS CODE%
30 PRINT "WAITING FOR REMOTE RESPONSE"
40 PRINT "PRESS ANY KEY TO ABORT"
50 OPEN "COM1:9600, N, 8, 1" AS #1
60 ON COM(1) GOSUB 100
70 COM(1) ON
80 IF INKEY$="" THEN 80
90 COM(1) OFF : END
100 GET 1 : CALL VARPTR(CODE%)

If you can fit something in machine language that can fit into that 255 byte variable to then load something bigger to handle the floppies, you're golden.
 
Last edited:
Step 1) simple five or six line BASIC program to grab and run a small(ish) bootloader over serial

This isn't possible because Cassette BASIC (what is in the IBM ROM) doesn't support OPEN "COM1". If it did, this would be a very easy problem to solve :) The only argument ROM BASIC supports is CAS1 and one of the goals was to avoid having the user have to wire up a custom cable (plus, that wouldn't work with an XT or AT because they don't have cassette ports).

So the BASIC program would have to essentially be an x86 opcode block that handles, at least, the communication protocol so that a larger program can be uploaded to it.
 
This isn't possible because Cassette BASIC (what is in the IBM ROM) doesn't support OPEN "COM1". If it did, this would be a very easy problem to solve :) The only argument ROM BASIC supports is CAS1 and one of the goals was to avoid having the user have to wire up a custom cable (plus, that wouldn't work with an XT or AT because they don't have cassette ports).
Interesting to know -- I was working off the manual for the T1000SX's BASIC, didn't think it would be that crippled.

Shouldn't be THAT hard though to make a smallish callable machine language program to replicate that functionality though. I mean all you really need it to do is loop until the 255 byte buffer is full or a key is pressed to abort. how hard could it be?

Never really dealt with a PC that didn't have at least BASICA... or more specifically GW-BASIC. Time to dig up some manuals and read deeper what it can and cannot do when not started from disk. I'd have thought that would have been pretty basic functionality they'd have put into it.
 
how hard could it be?
Famous last words :) I have no idea, I've never programmed serial communications before. I'd likely lean heavily on the BIOS INT 14h routines, even though most people consider them garbage.

Time to dig up some manuals and read deeper what it can and cannot do when not started from disk.

To save you some time, I've made a BASIC reference available.

I'm not pursuing this at the moment, just tossing around ideas.
 
Back
Top