jmp.no/blog

Out of curiosity, I wanted to see if it was possible to have one binary file running on two different architectures - without modifications.

My target platforms were 32-bit x86 Win/DOS and, big surprise here, the C64. If only I could craft a header that the x86 would chomp through, I could sneak in a small JMP there to either x86 or 6510 code somehow.

The first thing I did was to create a minimal file on the C64, containing only the BASIC header which calls a machine code subroutine in the loaded program. The experienced user will recognize the program "0 SYS2062" in here:

00 0C 08 00 00 9E 32 30 36 32 00 00 00 00

Disassembling this on a PC yields the following result:

1858:0100 0008          ADD     [BX+SI],CL
1858:0102 000C          ADD     [SI],CL
1858:0104 0800          OR      [BX+SI],AL
1858:0106 009E3230      ADD     [BP+3032],BL
1858:010A 36            SS:
1858:010B 3200          XOR     AL,[BX+SI]
1858:010D 0000          ADD     [BX+SI],AL

This is looking good, this could actually work! The only thing worrying me is the SS:, but I can replace that with another instruction by modifying the SYS address. By changing the address to 2200, the disassembly looks like this:

1858:0100 0008          ADD     [BX+SI],CL
1858:0102 000C          ADD     [SI],CL
1858:0104 0800          OR      [BX+SI],AL
1858:0106 009E3232      ADD     [BP+3232],BL
1858:010A 3030          XOR     [BX+SI],DH
1858:010C 0000          ADD     [BX+SI],AL
1858:010E 0000          ADD     [BX+SI],AL

Exquisite! These instructions will not cause any problems for the code I'm about to append. So, the next step I did was to create a new file, simply printing "Hello world" out in DOS. I did this in DEBUG.EXE, in the lack of an x86 assembler.

1858:0100 B409          MOV     AH,09h
1858:0102 BA0901        MOV     DX,0109h
1858:0105 CD21          INT     21h
1858:0107 CD20          INT     20h

What follows at address $0109 is the text to be printed.

Next step was to merge the C64 header with the x86 code above, and at the same time include a test program for the 6510 processor. This time, I'm using the ACME assembler:

!CPU 6510
*=$800
!byte $00,$0c,$08,$00,$00,$9e,$32
!byte $32,$30,$30,$00,$00,$00,$00
*=$80e

; x86 code

!byte $90,$90,$90  ; NOP NOP NOP
!byte $b4,$09 ; MOV AH,9h
!byte $ba,$1c,$01 ; MOV DX,011Ch
!byte $cd,$21  ; INT 21h
!byte $cd,$20  ; INT 20h
!text "This program requires a Commodore 64.$"

*=$898 ; 2200

lda #0
sta $d020 ; set border color black
rts

Does it run in DOS? Let's see:

...and does it run on a C64? Does it? Does it?

IT DOES! Success! Now, off to write the first 32-bit x86 / C64 virus ever made, and conquer the world!

...and he delivers! Today, I finished the amvtg - ATmega Video Text Generator. It renders frames in NTSC black and white format (for compability) and it works fine on both of the PAL TVs I've tested it it on. It has a 37x17 text buffer which can be modified in real-time, for example via UART.

The project page is here. Hopefully, I can now stop obsessing on this and finally move on.

Ninja edit: Allright, I feel I have to add some information here after all. The screenshot above is 32x35 characters of ASCII text, but I have only made fonts for uppercase letters so far. It's still 99% C (one assembly inline for "NOP"), and there is still possible to make room for a couple of letters more. I think I might be able to do 35x35 by the evening. The secret was to enable the SPI2X register (d'oh!) and not wait for the SPI buffer to be drained; rather spend that time to preparing the next letter. And that was it, the resolution was more than doubled.

I'm currently just shy of using half of the SRAM: 32x35 characters (1120 bytes) as well as the font (640 bytes), in addition to some local variables. This would mean trouble for smaller controllers, like the ATmega8 and such, but I will do some experiments on storing the font in the program memory instead, and see if the read access is fast enough.

In summation, the code is minimal and very readable, and most people should be able to jump into it without too much of an effort. I'll release it this weekend after having tested it on a couple of other TV sets (I don't want to release non-functional stuff).

I have to calm down now so I don't obsess any further on this subject.

The textmode is finally perfect. I'm getting 16x15 characters, and I'm not asking for more. Pushing it further would have meant rewriting certain part in assembly, which I quite frankly don't feel like doing right now.

I'm using the SPI at full speed to push out the pixels for the characters, and the text can be manipulated in realtime, too (input via UART anyone?)

I will upload the code as soon, it just needs a little airbrushing first.

My vacation is over and it's time to get back to business. The good thing about getting away from it all, is the time you get to hatch on new ideas - and I have a shitload of them, ranging from minimalist computers to C64 peripherals and Pajazzo mainboards, and lots more.

My mailbox was blessed with two items while I was away, too. I first received a second-hand EVK1101 board I found on eBay a couple of weeks ago. This will be a major boost when it comes to microcontroller computing, although I must let go of my 8-bit habits first. Next arrival was an 8GB kit for my iMac, which finally lifts me up to a decent 12GB RAM. This helps a lot when you're running virtual machines like Windows (AVRStudio for Mac? Yes please) and Linux simultaneously.

Oh, and I finally caught up on Forth. That was fun, maybe I'll have something featuring AMForth one day.