code update

The egregious 6502 vs 6803 code comparison has been updated.  Yup, I was tired.  The 6803 code should be okay now.  While fixing the 6803 code, I also noticed the 6502 code looked like it could be improved.

The 6502 code from the shrapnel routine looks like it can be optimized as shown below.  Instead of incrementing z80_hl for every byte, use different y offsets, and then update z80_hl once.  The comparison is a little less lopsided with this change.

;----------------------------------------------------
; Explosion shrapnel.
;----------------------------------------------------

shrap:
    ldy #1
    lda (z80_ix),y         ; get the angle.
    clc
    adc #<shrsin        ; shrapnel sine table.
    sta z80_l
    lda #>shrsin
    adc #0
    sta z80_h

    ldy #0
    lda (z80_hl),y         ; fetch value from table.
    sta z80_e

    iny          ;#1
    lda (z80_hl),y        ; fetch value from table.
    sta z80_d

    iny          ;#2
    lda (z80_hl),y         ; fetch value from table.
    sta z80_c

    iny          ;#3
    lda (z80_hl),y         ; fetch value from table.
    sta z80_b

    lda    z80_l            ; add 4 to hl to advance pointer
    clc
    adc    #4
    sta    z80_l
    bcc    :+
    inc    z80_h
:

    ldy  #2
    lda (z80_ix),y         ; y coordinate in hl.
    clc
    adc z80_c        ; add cosine lb
    sta (z80_ix),y        ; store new coordinate lb.
    iny
    lda (z80_ix),y
    adc z80_b        ; add cosine lb
    sta (z80_ix),y        ; store new coordinate hb.
 

...

AGD porting notes (what is required to port AGD to a new system)

When asked if there is a guide to porting AGD to a new system, this was Kees van Oss's response on facebook:

Not really ... but this is how MPAGD works and what needs to be done to port it:

1. You start with an ASCII AGD file with commands to define graphics and the game behaviour. This AGD file can be created by converting an existing AGD4.7 game or create one with AGDX Studio or Jonathan Cauldwells WinAGD program.

2. The next step is to compile this ASCII AGD file into an assembler source file. The compiler converts all ASCII AGD commands into assembler code and adds the engine to the assembler sourcefile.
The engine is a library with routines which are called by the assembler code linked to the AGD commands.

3. After compiling, you need to assemble the assembler file into a binary file ready to run on the designed system. This assembler creates a tape or diskfile which can be used by the emulator.

4. After creating the tape or disk files, an emulator is called with the created tape or diskfile to test the game. So what needs to be changed to port MPAGD are:

- The converter, a C program (Step 1)
- The compiler, a C program (Step 2)
- The engine, a Z80 assembler file (Step 2)

You can use an existing assembler and emulator program to complete steps 3 and 4.

Things that need to be defined for a platform are:

- memory map definition
- screen handling
- sound handling
- keyboard handling

All blocks, sprites and objects are software handled by peeking and poking into screen memory so there is no hardware sprite handling except the MSX port which handles hardware sprites. The screen is based upon the ZX Spectrum, 256x192 pixels. The Spectrum has 16 colours with the limitation of a 8x8 block with 2 colours

- Blocks (tiles) are 8x8 pixels, max 255
- Sprites are 16x16 pixels, max 12
- Objects are 16x16 pixels, max 255

All these specs can be changed but all AGD4.7 games are based upon these specs.

Are you planning to port MPAGD to another platform because we have a Developers environment where you can discuss your porting problems.

several thousand lines later...

A lot of progress has been made, but... is it a bad thing for a game engine not to call functions like "shoot"?  I have a feeling I'll be looking at the original Z80 code.  On the bright side, I'm nearing the half way point converting the code.

The engine would be faster if the data structures stored X, and Y coordinates next to each other.  But I can't fix that since the game design tool would need rewritten.

... and another

This is a particularly egregious subroutine for the 6502.
I'm tired, so I'll have to double check the code later, but the 6502's 48 instructions are reduced to just 19 on the 6803. 

The 16 bit X index register, 16 bit D register, and not having to write the contents of HL until we need to change X makes a huge difference.  The 6502 has to store pointers on the direct page, and they are updated a byte at a time.  The 65816 supports 16 bits, so it should be more like the 6803 here.  The mode switching between 8 & 16 bit registers that can kill it's performance shouldn't be much of an issue.



;----------------------------------------------------
; Explosion shrapnel.
;----------------------------------------------------

shrap:
;    ldy #1
;    lda (z80_ix),y         ; get the angle.
;    clc
;    adc #<shrsin        ; shrapnel sine table.
;    sta z80_l
;    lda #>shrsin
;    adc #0
;    sta z80_h

    ldx        z80_ix

    ldab    1,x            ; get the angle
    ldx        #shrsin        ; shrapnel sign table
    abx                    ; X now contains z80_hl

;    ldy #0
;    lda (z80_hl),y         ; fetch value from table.
;    sta z80_e
;    inc z80_l         ; next byte of table.
;    bne :+
;    inc z80_h
;:
;    ldy #0
;    lda (z80_hl),y        ; fetch value from table.
;    sta z80_d
;    inc z80_l        ; next byte of table.
;    bne :+
;    inc z80_h
;:
;    ldy #0
;    lda (z80_hl),y         ; fetch value from table.
;    sta z80_c
;    inc z80_l         ; next byte of table.
;    bne :+
;    inc z80_h
;:
;
;    ldy #0
;    lda (z80_hl),y         ; fetch value from table.
;    sta z80_b

    ldd        2,x            ; fetch value from table
    std        z80_bc
    ;order changed because we use de below
    ldd        ,x            ; fetch value from table
    std        z80_de
    stx        z80_hl        ; still need to add 4 to hl, wait until done with de

;    ldy #2
;    lda (z80_ix),y         ; x coordinate in hl.
;    clc
;    adc z80_e        ; add sine lb
;    sta (z80_ix),y        ; store new coordinate lb.
;    ldy #3
;    lda (z80_ix),y
;    adc z80_d        ; add sine hb
;    sta (z80_ix),y        ; store new coordinate hb.

    ldx        z80_ix
    ; D still contains z80_de
    add        2,x            ; x coordinate,
    std        2,x            ; store new coordinate

;    ldy #4
;    lda (z80_ix),y         ; y coordinate in hl.
;    clc
;    adc z80_c        ; add cosine lb
;    sta (z80_ix),y        ; store new coordinate lb.
;    ldy #5
;    lda (z80_ix),y
;    adc z80_b        ; add cosine lb
;    sta (z80_ix),y        ; store new coordinate hb.

    ldd        4,x            ; y coordinate          
    add        z80_bc        ;    add cosine
    std        4,x            ; store new coordinate
  
    ldd        z80_hl        ; add 4 to hl
    addd    #4
    std        z80_hl

    rts

6502 vs 6803 code size example

Okay, who enabled auto completion by default on Notepad++?  This should be associate with the language rather than a global setting.  Now I have to turn it off, and on when I switch between C, and assembly.  😈

Since nobody's getting circuit boards out of China before CoCoFest, I don't feel a lot of pressure to write some code for a couple hardware projects I promised to help with.  So, I'm translating more code from 6502 to 6803 for the Teaser project.

Just to give you an idea of the difference in code size, I've commented out the 6502 instructions, and placed the equivalent 6803 ones after each section.  Notice how 8 instructions become 2 after iniob0, and 4 of the 6502 instructions are some of the slowest on that CPU?  It's like this everywhere.

The Z80 references are due to the original code the 6502 is ported from coming from the Z80, and they are duplicating the register use with memory variables.  Since the 6803's index register X is 16 bit, and can index anywhere in a 256 byte range off of X, we don't need to even change X here.  The 16 bit D register even lets us load, and save two bytes at once even though they are separate variables.
The 6803 is far superior for accessing data structures, and this project uses a lot of them.

The on significant difference vs the 6502, is the 8 bit loop counter is placed in memory, and decremented there.  Too bad Motorola didn't offer a direct addressing version of DEC, and INC instructions.  The dearth of registers on the 6803 makes the direct page an obvious place for loop counters.

Sorry, if Blogger does bad things to the code formatting.  I need to look up the page I was using to format, and colorize the code with off of my old computer.

;-------------------------------------------------------------
; Initialise all objects.
;
; Reset current room,y,x to start room,y,x for all objects
;-------------------------------------------------------------

iniob:
;    lda #<objdta         ; objects table.
;    sta z80_x
;    lda #>objdta
;    sta z80_i
;
;    ldx numob         ; number of objects in the game.

    ldx        #objdta        ; object table
    stx        z80_ix
    ;*************** use memory to hold loop counter
    ldaa    numob    ; number of objects in the game
    staa    loopcounter
   
iniob0:
;    ldy #35
;    lda (z80_ix),y         ; start screen.
;    ldy #32
;    sta (z80_ix),y         ; set start screen.
;    ldy #36
;    lda (z80_ix),y         ; find start y.
;    ldy #33
;    sta (z80_ix),y         ; set start y.

    ldd        35,x        ; start screen, find start y
    std        32,x        ; set start screen, start y

;    ldy #37
;    lda (z80_ix),y         ; get initial x.
;    ldy #34
;    sta (z80_ix),y         ; set x coord.

    ldaa    37,x        ; get initial x.
    staa    34,x        ; set x coord.

;    clc             ; point to next object.
;    lda z80_x
;    adc #38            ; distance between objects.
;    sta z80_x
;    bcc :+
;    inc z80_i
;:
    ldaa    #38        ; distance between objects.
    abx                ; point to next objects.

;    dex             ; repeat.
;    bne iniob0
   
    dec        loopcounter
    bne        iniob0
   
    rts

more on github

I just pushed the 6502 version of the code to print text on a graphics screen.
When I get time, the Atom, Atari, and Plus/4 code needs separated, and then I need to interface the code to the C compiler.

Teaser

This is something I started shortly before I got crazy busy last year.

What could I be translating from 6502 to 6803 assembly, and why does it keep saying z80?
😎

<sigh> Only 6000+ lines left to translate.

;--------------------------------------------------------------
; Display sprites.
;
; Input:
;  IX = sprite table
;--------------------------------------------------------------

dspr:
;    lda #(NUMSPR/2)        ; number of sprites to display.
;    sta sprcnt
    ldx        z80_ix
    ldaa     #(NUMSPR/2)        ; number of sprites to display.
    staa     sprcnt
dspr0:
;    ldy #0
;    lda (z80_ix),y         ; get sprite type.
;    cmp #255         ; is it enabled?
;    bne dspr1         ; yes, it needs deleting.
    ldx        z80_ix
    ldaa    0,x            ; get sprite type
    cmpa    #255        ; is it enabled?
    bne        dspr1        ; yes, it needs deleting.
dspr5:
;    ldy #5
;    lda (z80_ix),y         ; new type.
;    cmp #255        ; is it enabled?
;    bne dspr3         ; yes, it needs drawing.
    ldx        z80_ix
    ldaa    5,x            ; new type.
    cmpa    #255        ; is it enabled?
    bne        dspr3         ; yes, it needs drawing.
dspr2:
;    ldy #5
;    lda (z80_ix),y         ; copy new type.
;    ldy #0
;    sta (z80_ix),y
;    ldy #6
;    lda (z80_ix),y         ; copy new image number.
;    ldy #1
;    sta (z80_ix),y
    ldx        z80_ix
    ldd        5,x                ;copy new type 5 and image number 6
    std        0,x                ;> to 0 & 1
;    ldy #7
;    lda (z80_ix),y         ; copy new frame.
;    ldy #2
;    sta (z80_ix),y
    ldaa    7,x            ; copy new frame
    staa    2,x
;    ldy #8
;    lda (z80_ix),y         ; copy new y.
;    ldy #3
;    sta (z80_ix),y
;    ldy #9
;    lda (z80_ix),y         ; copy new x.
;    ldy #4
;    sta (z80_ix),y
    ldd        8,x            ; copy new y & x
    std        3,x
   
;    clc
;    lda z80_x
;    adc #(TABSIZ*2)        ; distance to next odd/even entry.
;    sta z80_x
;    lda z80_i
;    adc #0
;    sta z80_i         ; next sprite.
    ldd        z80_ix
    addd    #(TABSIZ*2)        ; distance to next odd/even entry. next sprite.
    std        z80_ix
   
    dec sprcnt
    bne dspr0            ; repeat for remaining sprites.
    rts
dspr1:
;    ldy #5
;    lda (z80_ix),y         ; type of new sprite.
;    cmp #255        ; is this enabled?
;    bne dspr4         ; yes, display both.
    ldx        z80_ix
    ldaa    5,x            ; type of new sprite
    cmpa    #255        ; is this enabled?
    bne        dspr4        ; yes, display both.
dspr6:
    jsr sspria             ; show single sprite.
    jmp dspr2

; Displaying two sprites.  Don't bother redrawing if nothing has changed.

dspr4:
;    ldy #4
;    lda (z80_ix),y        ; old x.
;    ldy #9
;    cmp (z80_ix),y         ; compare with new value.
;    bne dspr7         ; they differ, need to redraw.
;    ldy #3
;    lda (z80_ix),y        ; old y.
;    ldy #8
;    cmp (z80_ix),y         ; compare against new value.
;    bne dspr7        ; they differ, need to redraw.
    ldx        z80_ix
    ldd        3,x            ; a = old y, b = old x
    cmpa    9,x
    bne        dspr7        ; they differ, need to redraw.
    cmpb    8,x            ; compare against new value.
    bne        dspr7        ; then differ, need to redraw.

;    ldy #2
;    lda (z80_ix),y         ; old frame.
;    ldy #7
;    cmp (z80_ix),y         ; compare against new value.
;    jmp dspr7         ; they differ, need to redraw.
    ldaa    2,x            ; old frame.
    cmpa    7,x            ; compare against new value.
;    jmp    dspr7            ; they differ, need to redraw
    bne        dspr7        ; they differ, need to redraw
   
;    ldy #1
;    lda (z80_ix),y         ; old image.
;    ldy #6
;    cmp (z80_ix),y         ; compare against new value.
;    beq dspr2        ; everything is the same, don't redraw.
    ldaa    1,x            ; old image.
    cmpa    6,x            ; compare against new value.
    beq        dspr2        ; everything is the same, don't redraw.
dspr7:
    jsr sspric         ; delete old sprite, draw new one simultaneously.
;    jmp dspr2
    bra    dspr2
dspr3:
    jsr ssprib         ; show single sprite.
;    jmp dspr2
    bra    dspr2
   
sprcnt:    .byte 0

The magic MC-10 keyboard trick

On the last episode of the CoCoTalk podcast (talk show?) the news section brought up the following video, where a BASIC program reads garbage from the keyboard when you wave your hand over it.


https://youtu.be/o6zssRDSjuE

I gave a brief explanation of why this happens on the show, but here is a little more detail about what is going on.


The Motorola 6803 is a microcontroller. It differs a bit from most 8 bit microprocessors because it has some built in hardware.  Parallel I/O ports, serial port, timer, etc...  To keep things somewhat simple, the MC-10 keyboard is wired to one of the built in parallel I/O ports.  The program shown above sets that port to input mode, and then it just polls the input port, and prints whatever comes in on the screen.

The way the keyboard is wired to the 6803, it forms it's own buss of sorts on the system.  The wires and circuit board traces form little antennas which pick up noise.  It's been a while, but if I remember right, the human body can induce a current of up to 1.8 volts.  I don't have a scope to hook up to it for verification, but that's probably what we'd see.  While the port on the 6803 was designed to work with 5 volt parts, it seems just sensitive enough to pick up that voltage as high signals.  Since the voltage isn't continuous on all the lines, the numbers change somewhat randomly.

If the keyboard had used a 2 layer board with a ground plane on the top side, and just passed the key connections through from/to the other side, this probably wouldn't happen.  Also, if the keyboard buss had resistors tying the keyboard lines to ground on the read side of the circuit, that weak noise would have been dropped to a level that the 6803 wouldn't read.  I don't think this was a matter of money, the engineer probably just didn't see it as a buss, so he didn't expect it, and this didn't show up in testing.

So why doesn't it cause a problem for BASIC?  The BASIC interpreter outputs data to the keyboard to choose which row of keys to check, it performs debounce which dumps inconsistent data, etc...
I don't think the debounce is helping.  More likely, the 6803's I/O port design can't read that low of a voltage under those circumstances, and that only happens when it's set just as input and you poll it, but that's a bit of a guess.

More stuff on github

I'm dumping a lot of stuff to github. 
Github

The code for the expansion board I was working on for the VZ200 is up on github.
VZ Super-Expander


The IDE interface was going to be based on the TRS-80 Lo Tech interface.
The CPLD was just going to be used for address decoding to keep the pin count down.  That would require some external chips for buffering, LED, etc..., but it was only two or three parts I remember right.  The driver was going to be based on modified code from the Lo Tech driver just to keep things simple.

My project to do list:


A chess game for the MC-10.  People asked me to do this, so some point in the next few months I'll see what I can do about it.  They suggested I port MicroChess from the 6502, but if I can get the 6803 C compiler to actually build working code, you'll get a lot better chess game than that.  The compiler seems to have some stack issues at the moment, so no promises. 

More MC-10 ROM changes in the works, including a faster LOG function.  The new LOG will eliminate some of the slow division in the current code, replacing it with multiplication that will use the hardware multiply instead.  Functions that depend on LOG should be significantly faster, including SQR, SIN, and COS.  Combined with the previous SIN, COS speedup, the 0.89 MHz MC-10 might beat the 1.77 MHz CoCo 3 generating that "Fedora" 3D plot, and Ahl's Benchmark will drop below the 1 minute mark, possibly around 45 seconds.  That's half the factory ROM's original time.  Another change is to drop the ELSE statement.  Yeah, that's the first thing I added, but after the last round of changes, it's just slowing things down.  The interpreter has to search for the end of the line looking for an ELSE statement when an IF fails.  Without it, the interpreter just loads the address of the next line, and starts interpreting code.  Hopefully, that will speed up non-math oriented code enough to top the 10% mark.

Port BASIC to a 68HC11 development board.  I've made a lot of the changes already, but it will only use terminal I/O, so lots of stuff has to go.  At the moment, the board is just sitting on my desk staring at me. 

A few years ago I ported the UCSD Pascal P-Code (bytecode) interpreter to the 6803.  The 16 bit support, 16 bit index register, and a few other features makes the code smaller, and faster than the 6502 version (the Apple Language System).  I *think* all that's left to implement is the hardware interface code for the UCSD P-Machine.  But it's never that easy is it?  The MC-10 hardware is right in the middle of the memory map, and there is no disk drive.  The MC-10's design does allow external hardware to disable the internal memory map (video, sound, ROM, and internal RAM), so, it just needs an external expansion that can disable this stuff.  The MCX-128 will do some of this, but it doesn't work with the hi-res mode, so using my 64 column graphics text code is out.  That leaves the 32 column, uppercase only, inverse "lowercase", VDG output for text.  That would be horrid for Pascal.  Maybe some hardware is needed here.  Hmmmm...

The P-Code interpreter for Tiny Pascal (BYTE Magazine, 1978) may get a port.  It's similar to UCSD Pascal, but it's simpler.  A program could be compiled on the PC, and the bytecode could be tacked on to the end of the interpreter, allowing the whole thing to load from cassette.  It might be fun to play with, but it's not a priority.

While I'm talking about bytecode interpreters... the author of FastBASIC for the Atari asked if I'd port the it's bytecode interpreter to the 6803.  It would need over 2000 lines of assembly.  I have avoided starting on it until I finish some other projects, but a few people may prefer BASIC over Pascal.

Finish the disassembly of the VZ-200 ROM.  I was using msys (a Unix like development system that works under Windows), but someone broke the sed command in an update.  The disassembly uses an automated script to generate code, labels, and to attach comments to the disassembly using sed.  My new desktop machine has a Linux boot drive I can use when things like this happen, and hopefully sed isn't broken there as well.


I'm going to start uploading code to github including:
 
The Oric music player, the Apple II Mockingboard version, and the VZ200 version.

A port of the William Tell Overture 4 voice music program from the CoCo, to the VZ.  This is unfinished since I no longer have hardware to test on, and having someone else in Australia test it just wasn't working. It had some sort of bug as of the last test, which I may have found, but it doesn't have all the music data.  I don't have the magazine with the source code anymore, so I'd have to extract the data from the CoCo executable.

Some Veralog code for a VZ200 RAM, FLASH, IDE, sound board I was working on.  It's just some address decoding, generating chip selects, and a small amount of address line generation for the paged memory.  The pin count was a bit high for a small CPLD, so I was planning changes, but my VZ burned up with my house, so it hasn't been touched since.  It's about 600 lines of verilog.

The 64 column, graphics text code for the 6502, Z80, and 6803.
That includes Atom, Atari, Plus/4, VZ200, and MC-10 versions. 
The Plus/4 code still needs to set the graphics mode, and the memory map.
The Z80 VZ, and 6803 MC-10 versions have some untested optimizations.
As I work on this, I'll post video updates.  Hopefully the quality will be better now.

No I'm not dead... not yet anyway

No I'm not dead, and my projects aren't dead.  I just got busy working for several months, and I've had some computer issues. One laptop is totally dead and the other is kinda in two pieces.  My new PC (AMD Ryzen 2700X), is gradually getting all the tools installed including multiple compilers, assemblers, custom syntax highlighting definitions, disassemblers,  Quartus, PCB design tools...

Some projects are going to be placed on github, including some projects I've never mentioned.