So cartridges in PCjr are actually PC BIOS extensions with 055h 0AAh in the beginning and this is how they checked on boot:
with step 2K it's looking for 0x55 0xAA signature and then check CRC:
And this piece shows how BIOS determines which algorithm to use - CRC16 or simple arithmetic sum:
So in order to create proper BIOS extension I wrote CRC16 library compatible with IBM's CRC_CHECK (see here) and special program that creates ROM image from COM-file (for now it has to be specifically created "read-only" COM-file) and put CRC at the end of that ROM image - PCJRCART.C
And this is my 1st program (pictured as title image of the project):
org 100h section .text start: MOV BH,7 ; 0 for DOSBox MOV BL,4 MOV CX,1 MOV DH,18 MOV DL,0 LEA SI,[STRI] NEXT: MOV AH,2 INT 10H INC DX MOV AL,[SI] CMP AL,'$' JE KON MOV AH,9 INT 10H INC SI JMP SHORT NEXT KON: JMP KON section .data STRI DB 'Hello, Hackaday ! $'
Program is compilable by this command (you need NASM):
nasm test1.asm -fbin -o test1.com
now it could be tested in DOSBox for example or from DOS prompt on real machine and then pcjrcart test1.com to produce test1.bin that could be directly written into AT28C256 (or AT28C64 if size<=8K)
UPDATE: This approach (with some tweaks) was successfully used for PC XT machine by @esot.eric :)
https://hackaday.io/project/18868-improbable-secret-project/log/51957-we-have-a-bios-extension
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
FYI, found out the hard way... PCjr's method for verifying the BIOS extension is different than PC/XT's (which just uses a checksum, rather'n a CRC) :)
This is handy, either way... I've got my .COM running!
Are you sure? yes | no
Excellent :)
I added another photocopy of the Tech Reference above to show how everything is working together - PCjr BIOS checks CRC16 for adresses above D0000 and simple sum below D0000:
https://cdn.hackaday.io/images/2168391484526882855.jpg
And yes, now I have paper version of "PCjr Technical Reference" (bought as "brand new") with SCHEMATICS!!! :)
Are you sure? yes | no
Awesome!
I see, now the test you're talking about... I'll have to look more thoroughly at the XT code, as it does seem to treat "rom" as differently from "ros" (whatever that is).
It's funny, about 6 months ago I sold a PCjr that'd been sitting around in my storage for decades, even had the paper techref, but didn't look into it thoroughly enough to realize it had that level of detail. I thought it just talked about how to install floppy drives, printers, etc. But I never really used the PCjr, it was given to me after I'd gotten used to my PC/XT (from a garage sale with *boxes* of stuff for $20!).
Are you sure? yes | no
@esot.eric Do you have some leftover by the way from that PCjr? As software, cables, extension boards, mice etc? :)
Are you sure? yes | no
@Shaos well, now I wish I did... Would you believe it had two copies of the manual and some other docs... Was trying to recover space, so made sure *everything* went with it :/
Are you sure? yes | no
Unbelievable :)
Are you sure? yes | no
Was just browsing the XT's BIOS assembly-listing a few weeks ago... I find it utterly amazing they actually make that detailed info available, and the comments are so thorough!
Is it too early in the process to ask what you plan to load on your ROM-cartridges?
Are you sure? yes | no
For now it's "Hello, World" and copies of existing cartridges
For future it will be arbitrary COM or EXE files and may be even DOS itself :)
Are you sure? yes | no
Cool. The Disk Operating System, without a disk :)
Ah hah! I see the "Hello Hackaday!" update. Awesome!
Are you sure? yes | no
I think that some computers had MSDOS in firmware... Tandy maybe ?
Are you sure? yes | no
And may be I'll try to put some PIC16 with PSP into cartridge to test is as co-processor ;)
Are you sure? yes | no
@Yann Guidon / YGDES, I think I've read the same, recently. Another was one of the PSION devices(?). Still the concept is funny.
@Shaos got me thinking... these cartridges don't appear to toggle /OE (so I guess it's just assumed with /CS). OTOH, at the ROM-level, there might be nothing preventing you from requesting a "write" to one of these addresses, you just wouldn't get the /WE signal (for e.g. an SRAM or I/O device)... so map a certain range of addresses for write-only? (I guess, assuming the data-lines aren't buffered)
Are you sure? yes | no
@esot.eric my idea to emulate write is to read from range 0x7FXX where XX is byte to write into PSP of the PIC (or to write into memory chip, but address should be set before that in similar fashion by reading from 0x7Exx and 0x7Dxx) - something like that :)
Are you sure? yes | no
@Shaos Ah hah! That method would be immune to unidirectional data-buffers, as well!
Are you sure? yes | no