ADTPro for PC?

[deathshadow]

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.

They're only garbage if you're trying to go outside what they were designed to do.... like go past 9600 baud. You go 9600, N, 8, 1 for something simple like this, it would keep the amount of code needed under control.

Something like this:

; waitSerial (COM%, CODE%, BYTES%)
waitSerial:
	push bp
	mov  bp, sp
	mov  ax, 0x00E3 ; 9600, N 8 1
	mov  dx, [bp + 10]
	int  0x14
	mov  di, [bp + 8]
	mov  cx, [bp + 6]
nextChar:
	mov  ah, 0x01
	int  0x16
	jnz  done
	mov  ah, 0x02
	int  0x14
	test ah, 0x80
	jnz  nextChar
	stosb
	loop nextChar
	mov  di, [bp + 6]
	jmp  [ds:di]
done:
	pop  bp
	ret  4

Should get the job done -- thankfully DX isn't corrupted later in the code making our lives a LITTLE easier in tracking the COM port.

Reasonably small compiled at 45 bytes, so the BASIC loader would go something like this:

10 COM% = 0 : BYTES% = 255
20 PRINT "Loading Machine Language Routine" : READ CSIZE
30 DIM CODE%(CSIZE) : MEM% = VARPTR(CODE%(1)) : ROUTINE = MEM%
40 FOR I=1 TO CSIZE : READ V : POKE MEM%, V : MEM% = MEM% + 1 : NEXT
50 DIM BUF%(BYTES%)
60 PRINT "Load complete, start server transfer or hit any key to abort."
70 CALL ROUTINE(COM%, BUF%, BYTES%)
80 PRINT "Aborting" : END
100 DATA 45, &H55, &H89, &HE5, &HB8, &HE3, &H00, &H8B, &H56, &H0A
110 DATA &HCD, &H14, &H8B, &H7E, &H08, &H8B, &H4E, &H06, &HB4, &H01
120 DATA &HCD, &H16, &H75, &H12, &HB4, &H02, &HCD, &H14, &HF6, &HC4, &H80
130 DATA &H75, &HF1, &HAA, &HE2, &HEE, &H8B, &H7E, &H06, &H3E, &HFF, &H25
140 DATA &H5D, &HC2, &H04, &H00

Note that I put the length as the first byte, makes it easier to modify later. I THINK that would work, completely untested though and it's been ~30 years since I've even looked at BASIC in any sort of serious manner. Also remember that COM% = 0 would be COM1.

At around 700 bytes of BASIC code that wouldn't be the end of the world to type in as your "first start" -- naturally once you had a working boot disk you'd want a more robust disk based solution, but if you had NO other way of getting to the point of making floppies this would get the job done. Small 45 byte loader that loads a larger 255 byte routine over serial that loads an even bigger one if need be... One could also expand it to try and find a larger open segment of memory and just make it load more code directly, I just figured use an array so that you can have a safe abort back to BASIC if need be. If you didn't care about going back to BASIC, the ASM and BASIC code could be simplified further.

Though it's often shocking how much functionality can be packed into 255 bytes.

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

Yeah, I'm kinda just throwing ideas out there too. Anyone wants to pick it up and run with it, knock yourselves out.

 

[deathshadow]

Oh, I also like the idea of making a device that interfaces via the keyboard port -- even a cheap $3 arduino knockoff from Korea could handle that. Easier to do for AT's, but that's just because most of the grunt-work is done for that. Even so, I'd probably make the little basic program load ASM off the pretend keyboard device to then run and do more complex stuff.

Though... what's the throughput on a XT keyboard interface? I wouldn't think it would be the peppiest of device interfaces on a PC. Certainly the best supported though!

 

[Chuck(G)]

Since an XT keyboard port furnishes both data and clock, it's easy enough to implement by using another PC's printer port and a suitable cable. Done that years ago, BTW.

 

[reenigne]

Though... what's the throughput on a XT keyboard interface? I wouldn't think it would be the peppiest of device interfaces on a PC. Certainly the best supported though!

For receive it's actually quicker than serial and parallel put together! The ROM routine can get over 41KBytes/s and even faster speeds could be achieved by asynchronous byte timing.

Send is also possible by bit-banging the clock line and I have a routine for this that goes at about 10KBytes/s (faster speeds could be achieved at the expense of bulkier code).