Sunday, February 17, 2019

Coleco ADAM IDE, Multi-Cart.Boot Code

This is the code I created in 2013 to auto boot the Coleco Adam IDE interface via a game cart.  After seeing the IDE driver had to be loaded from tape, or with a ROM plugged into a parallel board, I asked if there was a version that loaded from a multi-cart.  There wasn't so I volunteered to write it.

More time was spent reading documentation on the ADAM, and disassembling the existing ROM than on creating the loader code.  It simply changes the ADAM memory map settings, copies the driver into low RAM, then it jumps to that code which sets the final memory map, and copies the driver to it's proper address.

The actual driver code data is left out since I don't own the copyright.  I thought it was worth sharing because someone could use this as a starting point to copy other programs from cart to RAM.  Source for the lower RAM code that copies the driver to it's final address had to be assembled separately, and it is also missing, but you can see the first few lines of code in the data starting at LOWRAMCODE.
The <snip> indicates where the driver data was removed.  This code was assembled using the TASM assembler, which requires the #defines at the start, and interrupts are re-enabled once the driver is in place.   The code may have been shared on a forum previously. 


;*****************************************************************
;* IDE Boot Cart.asm
;*****************************************************************
;* Loads the MICRO-INNOVATIONS boot EPROM from a game cart
;* and launches it from intrinsic RAM.
;*****************************************************************
; define standard assembler directives to work with TASM
#define org .org
#define end .end
#define byte .byte
#define word .word

#define DCB  .byte
#define dcb  .byte

#define DCW  .word
#define dcw  .word

;*****************************************************************
;* test cart header
;*****************************************************************
 org $8000 ; start of cart memory
 
 DCB $55,$AA ; test cart ID
 DCB 00,00,00,00,00,00,00,00 ; filler, we don't use this
; org 800AH  ; location of cart start address
 DCW CARTSTART ; cart start address, used to execute cart code
;*****************************************************************

;*****************************************************************
;* the first code executed in the cart 
;*****************************************************************
CARTSTART:

 di   ; interrupts would be bad during this process

 ld a,%00001101   ; 32K lower intrinsic RAM + cartridge ROM
 out ($7F),a    ; set memory map

 ld hl,$45ed   ; interrupt handler
 ld ($0066),hl   ; set interrupt vector
 
 ; copy code from cart into 32K intrinsic RAM
 ld hl,LOWRAMCODE   ; start
 ld de,$0100    ; destination... low RAM
 ld bc,ENDCODE - LOWRAMCODE ; length
 ldir

 jp $0100     ; call code in 24K intrinsic RAM

; start of the eprom data
; we duplicate what this does but from cart ROM so we skip it
;BOOTCODE:
; dcb  $66,$99,$F3,$3E,$05,$D3,$7F,$21,$ED,$45,$22,$66,$00,$21,$1B,$80
; dcb  $11,$00,$01,$01,$7B,$06,$ED,$B0,$C3,$00,$01

LOWRAMCODE:
 
 dcb  $3E,$01  ; ld a,$01
 dcb  $D3,$7F  ; out ($7f),a
 
 dcb  $21,$12,$01 ; ld hl,$0112
 dcb  $11,$00,$80,$01,$69,$06,$ED,$B0,$C3,$00,$80,$ED,$4B,$43
<snip>
ENDCODE:
 end
 

Wednesday, December 12, 2018

Apple II vs MC-10

Apple II vs the MC-10 with the new ROM.  It would be worse if I hadn't optimized the original code by moving some calculations outside of the loops.

The images look very different, but the only difference is the scale and center of the image.  They are performing the same number of calculations and setting the same number of pixels.  Once I add hi-res graphics support this will be more obvious.

New CoCo 3 ROM

For those of you that want a new CoCo 3 ROM, I've turned my current code over to William Astle.
Pretty sure he'll be able to crank out the 6809 changes faster than I would since I haven't been working with the 6809 much.  This will also leave me to work on a few other optimizations I had in mind.

Monday, December 10, 2018

Finding Prime Numbers

Another speed comparison, finding prime numbers up to 10,000.



Thursday, December 6, 2018

CoCo 3 vs MC-10 with new ROM

Up to this point I've shown comparisons of the new vs old MC-10 ROM.  This video demonstrates  the difference in speed between the CoCo 3 running at double speed vs the MC-10 with the new ROM.  This is the difference the hardware multiply makes, along with a better implementation of the interpreter.  The CoCo 3 will show a greater difference on non-math oriented programs, but this provides a rather interesting comparison.  If I were to replace the MC-10's Motorola 6803 with a Hitachi 6303, and if it provided even a 10% speed increase, the MC-10 would win in this comparison.   The 6309 provides at least a 20% speedup over the 6809 so that is a very real possibility.

Wednesday, December 5, 2018

Some last minute notes on the new MC-10 ROM

Just some notes on last minute changes to the new MC-10 ROM.

The 16 bit string compare may be a few clock cycles slower when comparing strings of 1-3 bytes in length(?), but anything longer will be faster.  The slower performance on short strings will be more than made up for by the faster interpreter, but the difference on longer strings is significant enough to make this change well worthwhile.  The new interpreter will always be faster, but should be noticeably so when comparing a lot of long strings like with my test sort code (which I'll release shortly).

The manner in how the the main loop calls the functions associated with tokens has been changed. 
The size of the "Command Dispatch Table" has been enlarged to account for all potential tokens.  This allowed the removal of the range check before calling the address in the Command Dispatch Table, saving a few clock cycles.  Tokens that would result in a syntax error, now jump directly to the error, and undefined tokens jump to the RAM hook "RVEC10" which is set to jump to syntax error by default.  This lets the main loop skip the jump to the RAM hook for every ROM based token routine, saving multiple instructions for every token executed, but you can still intercept unused tokens to extend the ROM.
While existing programs that override tokens will not work on the new ROM (I can only think of one), it is still possible to extend BASIC, and alternative versions of existing commands could replace the current ones.  I'm working on a way to embed new tokens and parameters directly into the code.

*edit*
Please note that tokens $F0-$FF cannot be used at this time.  The token number is multiplied by 2 to calculate the offset in the dispatch table.  This is done with a bit shift, but the result is only one byte and the carry is lost.  It's a trade off for speed.  It still leaves room for 38 new tokens, and I'd like to reserve $EF for future expansion.  (Two byte tokens could be a possibility in the future)

Monday, November 26, 2018

MC-10 ROM fixes before a release

The bug in the code that converts ASCII to floating point by changing divide by 10 to multiplying by 1/10 is now fixed.  This offered a significant speedup, so I'm happy that code will make it into the release.  That leaves one bug to fix before an official release.  That bug is likely to be in the math library, and I'm pretty sure I know what it is.  Once I get time it shouldn't take too long to fix.  The first release will definitely be a 16K ROM, but an 8K ROM with most of the code may follow if it will fit.  I am not going to fight with it to get that working though.

You can see the bug in my youtube video with the sort comparison.  The gap values are different between the original and new ROM.  That is no longer the case.  FWIW, the the constant for 1/10 was wrong and it was the first thing I checked, so... easy fix.