Jr Cartridge blank for eprom

[Shaos]

makes sense then why colorpaint when launched directly from my "carts on floppy" disk fails to load. No DOS == no worky. If I ever go back into that project for another update I will remove colorpaint completely.

or you can make your disk DOS-bootable and call your menu program from AUTOEXEC.BAT instead of boot sector

[Shaos]

It would be oddly cool to take this project:
http://www.brutman.com/forums/viewtopic.php?f=3&t=364
where I converted a bunch of cartridge games to run off a floppy disk and convert it back to running entirely off cartridge again!

I don't quite recall how much storage space all of the games require. My project fits easily on a 360k floppy disk, but I seem to recall that nearly half of the disk is still blank, so a single cart that booted up with a little menu and allowed you to pick any of the games would be fun indeed. A PCjr megaGamesCart!

About 230KB as I see - I think I can try
You even put offsets in the DETAILS.TXT - it's very helpful

P.S. It's compressible to about 100KB and I think I can put it to TWO 64KB cartridges (or ONE future 128KB cartridge that I'm also going to make)

P.P.S. Without colorpaint (that requires DOS) archive will be even smaller than 100KB...

ok - done
with simple compression when 3 and more zeros represented as 5 bytes "00h 00h 00h LOW HIW" 8 games and 256-byte loader took almost exactly 128KB
so in order to make it you need 2 64KB cartridges (or 1 future 128KB cartridge with 4 chips on the same longer board):



one cartridge must be set to range D0000-DFFFF and second cartridge - to range E0000-EFFFF.

Then you need to download image from topic http://www.brutman.com/forums/viewtopic.php?f=3&t=364, software from my GitHub and NASM:

1) Take file JRCARTS4.IMG from ZIP-archive and put it to the same directory where JRCARTS4.EXE is located then launch it - it will prepare compressed image JRCARTS4.BIN for the next step;
2) Execute JRCARTS.BAT that will assemble JRCARTS.ASM (with incbin "jrcarts4.bin" at the end) to JRCARTS.BIN with size 131067 (that is 5 bytes less than 128KB);
3) Execute JRCARCRC.EXE to make sure that CRC of the first 512 bytes of JRCARTS.BIN is 0000h (otherwise PCjr will refuse to launch it).

Then you need to program this file to 4 AT28C256 EEPROM-devices with offsets #00000, #08000, #10000, #18000 and that's it



P.S. Because I needed loader squeezed into 256 bytes I shortened game titles (as you can see I took LOADER.ASM from original package and significantly rewrote it : )

Code: Select all

;JRCarts loader
;jeff leyda
;2014
;jeff@silent.net
;
;Modified by Shaos for PCjr cartridge and NASM (2017)

MAX_GAMES       EQU     7 ; 8
LOAD_SEG        EQU     2000h

        org 0

section .text

        db      55h,0AAh,1 ; check CRC only for first 512 bytes
        jmp     main
        db      6Ah,59h ; 2-byte placeholder for CRC correction

; 0) 0x55 0xAA 0x10 (8192 bytes)  current=0x00000 (0x00100)
; 1) 0x90 0x90 0x10 (8192 bytes)  current=0x01FBF (0x020BF)
; 2) 0x55 0xAA 0x20 (16384 bytes) current=0x03FA8 (0x040A8)
; 3) 0x55 0xAA 0x20 (16384 bytes) current=0x07EA1 (0x07FA1)
; 4) 0x55 0xAA 0x50 (40960 bytes) current=0x0BD2F (0x0BE2F)
; 5) 0x55 0xAA 0x50 (40960 bytes) current=0x144D4 (0x145D4)
; 6) 0x55 0xAA 0x10 (8192 bytes)  current=0x1C3D3 (0x1C4D3)
; 7) 0x55 0xAA 0x10 (8192 bytes)  current=0x1E154 (0x1E254)
; maxzero=8192 nonzero=120109 current=130811 (0x1FFFB)

loadTbl:        db      20h,0,  1h,  0h, ; scubaventure
                db      20h,0, 20h,0BFh, ; mouser
                db      40h,0, 40h,0A8h, ; river raid
                db      40h,0, 7Fh,0A1h, ; pitfall II
                db     0A0h,1, 3Eh, 2Fh, ; demon attack
                db     0A0h,2, 45h,0D4h, ; microsurgeon
                db      20h,2,0C4h,0D3h, ; crossfire
                db      20h,2,0E2h, 54h, ; mine shaft
main:
        mov     ax, cs
        mov     ds, ax

        mov     ax, 2           ; set 80x25
        int     10h
        mov     ax, 500h
        int     10h

        xor     bx, bx          ; page# for these routines
        lea     si, [menuText]
printString:
        lodsb
        cmp     al, 0
        jz      input
        mov     ah, 0eh
        int     10h
        jmp     printString

input:
        xor     ax, ax
        int     16h

        sub     al, 30h         ; make input a value
        cmp     al, MAX_GAMES
        ja      input           ; retry dummy!

        lea     si, [loadTbl]
        shl     al, 1
        shl     al, 1
        xor     ah, ah
        add     si, ax          ; si now points to load info

loadit:
        mov     bx, LOAD_SEG    ; segment to load games into
        mov     es, bx

        mov     ch, [si]        ; size in pages (256 bytes)
        mov     cl, 0           ; cx is now size in bytes
        mov     ah, [si+1]      ; segment magic
        mov     bh, [si+2]      ; higher offset
        mov     bl, [si+3]      ; lower offset

        cmp     ah, 1           ; check if data is too far
        je      next1
        cmp     ah, 2           ; check if data is way too far
        jne     loadit_

        mov     ax,ds
        add     ax,1000h
        mov     ds,ax
        jmp     loadit_

next1:  mov     ax,ds
        add     ax,0800h
        mov     ds,ax

loadit_:
        mov     si,bx
        xor     ax,ax
        mov     di,ax
        mov     bx,ax

loadit_1:
        mov     ah,[si]
        mov     [es:di],ah
        inc     di
        inc     si
        cmp     ah,0
        jne     loadit_2
        inc     bx
        cmp     bx,3
        jne     loadit_3
        mov     bl,[si]
        inc     si
        mov     bh,[si]
        inc     si
        sub     bx,3
        jz      loadit_3
        sub     cx,bx
loadit_1a:
        mov     [es:di],al ; zero
        inc     di
        dec     bx
        jnz     loadit_1a
loadit_2:
        xor     bx,bx
loadit_3:
        dec     cx
        jnz     loadit_1

        xor     ax, ax
        mov     ds, ax
        mov     ax, LOAD_SEG    ; jump to segment:3 to start rom
        mov     bx, 3
        push    ax
        push    bx
        retf

menuText        db "0.Scub "
                db "1.Mous "
                db "2.Rive "
                db "3.Pitf "
                db "4.Dem "
                db "5.Mic "
                db "6.Cro "
                db "7.Min"
                db 0
compressed:
incbin "jrcarts4.bin"

P.P.S. All source codes in C/C++ for Borland are also available on my GitHub: https://github.com/shaos/pcjrcart

[Shaos]

Later I can make video of playing all of them, but for now just 2 pictures

[Hargle]

fantastic work!

We should give the bootloader to one of those demo scene guys who can put an entire chess game into a boot sector to see if they can optimize it further to make the menu pretty but still fit.


I talked with a friend last night who is going to help me create empty cart shells.
Are you going to be creating/programming/selling the 128k version? Are there any different eeprom types that could be used instead of the 32k chips you're using now to reduce the overall size?

[Shaos]

fantastic work!

We should give the bootloader to one of those demo scene guys who can put an entire chess game into a boot sector to see if they can optimize it further to make the menu pretty but still fit.

After I'll get experience how to write for ROM using C/C++ then I'll do better compression (like zlib) and then it will be much more space for loader with graphics and all this stuff

I talked with a friend last night who is going to help me create empty cart shells.
Are you going to be creating/programming/selling the 128k version? Are there any different eeprom types that could be used instead of the 32k chips you're using now to reduce the overall size?

Problem with bigger sizes EEPROMs is you need to add additional logic (as in SuperCART) to convert separate chip selects into extended address, so I see my future 128KB cartridge simply like longer version of this cartridge with 4 chips 32KB instead of 2...

P.S. Corrected link to my GitHub above

[Trixter]

We should give the bootloader to one of those demo scene guys

(Trixter bursts through the door) Did someone call for a demoscener?

Looking at the github code, I don't see many opportunities for optimization other than:

loadit_1 which is begging to use AL so that 4 lines of code can be replaced by MOVSB to save 6 bytes

loadit_3: Replace dec cx/jnz with LOOP to gain a byte and speed

I would advice against writing it in C and then trying to use zlib. The zlib decompression code stands a good chance of taking up more space than it will save, and the boot loader itself in C will be at least 4x larger. If you want a small decompression routine, try LZ4; I wrote one in 77 bytes. More info, including the windows command-line compressor to use with the decomp code, here: http://www.oldskool.org/pc/lz4_8088

[Shaos]

Russian demosceners use MegaLZ, so I may try it instead

About MOVSB - I thought about it, but problem is I need to check that copied value is 0, so I must keep it somehow - that's why copy through AL

About LOOP - I completely forgot about it (my 8086 experience ended around 1994 when I switched to pure 32-bit C) - thanks!

[Trixter]

Russian demosceners use MegaLZ, so I may try it instead ;)

LZ4 and ZX7 max out their respective pareto frontiers. I co-wrote the x86 decompressors for both, so I'm biased, but they are the fastest 8086 decompressors for their formats, and both have optimal parsing built into the compressors so they achieve competitive results. ZX7's size-optimized decompressor is 71 bytes and it compresses better than LZ4, so maybe look into that?

Beyond that, you start to get into exomizer territory (very high compression ratio), but I haven't written a decompressor for that yet.

About MOVSB - I thought about it, but problem is I need to check that copied value is 0, so I must keep it somehow - that's why copy through AL

Okay, so use LODSB to load it to AL and then STOSB to store it. That's 2 bytes and you get to keep it in AL, and you won't need the INC SI and INC DI any more.

[Shaos]

ok, thanks! I'll check

P.S. ZX7 is when ZX-Spectrum and PC worlds collide?
BTW ZX-Spectrum (and his clones) is my another obsession

[Shaos]

I just burned ColorPaint into my cartridge clone and run it from DOS:



Without mouse it's useless, but at least it's working

So in order to run it you need DOS - at least bootable disk - for example "Your PCjr Sampler" - just press Fn-B(Break) when it's drawing menu and then press Y to terminate batch job (ColorPaint cartridge should be inserted at this point) then simply write G in command line and Enter ("G" is DOS command from cartridge that execute ColorPaint application from DOS).

OK, I've connected the mouse (this particular one with RS-232 interface was bought in RadioShack about 13 years ago) through 2 adapters - official IBM PCjr-to-DB15M then DB15F-to-DB9M (as you can see I bent adapter's ears a little to make it fit) and then mouse with DB9F connector - it's working!



Some drawing with fill tool



And the same screen on modern LED TV connected through composite (hello, color artifacts):