50 replies to this topic

[The Usotsuki]

I've been developing for another 6502 system for a while (as well as having ported over a better BASIC than it had in the ROM), and a friend of mine told me about the 7800 expansion chassis being developed.  It in and of itself didn't intrigue me so much as what it would be with 2 more things attached - a keyboard (which there seems to be a call for), and a disk drive of some sort (which, since I'm led to understand the chassis has a SIO port, could be taken from the 400 line).  That all together, the hardware would be settled, and we would be up to where I'm trying to get - which is software.

A while ago, I ported EHBASIC to the Apple ][ line.  I mulled over the possibility of porting it to a potential keyboard-ized Atari 7800, although since, I rejected it because of the *code* similarity to Microsoft's dialect (including bugs) which means that using it as a sort of firmware on a cartridge - which I wanted to do - would be a big no-no.

So there's a few things I'd want to do, some of which I can already do, and some of which I can't do.  The most important thing would probably be setting up some sort of a terminal driver, which would be the linchpin - every OS needs a way to output text to a screen! xD

At this point I know very little about the 7800, but would need only to find enough information to set up a screen layout suited to writing text on a screen.  I've got a font suited to the task - 8x8, 1 bit per pixel, modified Atari 400 font, done with an eye for implementing a cursor in software.

(Yeah, I'm a noob here.  I do have a 6502 development toolchain already though from my Apple ][ work.)

[The Usotsuki]

An addendum.



I don't know anything about the 7800 beyond the CPU, but coding for the 6502 is a hobby of mine, and I do want to actually make something of this idea.  Obviously the first and most important step here is the display code, which is also the only part that doesn't require even the expansion chassis to be done, let alone a keyboard for it.  The screenshot is from a font tester I wrote a few years ago to smoketest PC BIOS-style fonts.  I modified the Atari 400 ROM font into one that suited my needs, moving two of the card suit graphics around and adding the four characters { } ` ~ designed to look like the other characters, and aligning the font to follow ASCII conventions (with the high bit used for inverse, a convention which I have used on previous projects).

Once it is possible to create a 40x24 array of tiles, each containing one 8x8 glyph, then I can write the code for PUTCH.  The rest, GETCH, is going to require an input device which does not, as of yet, exist (though there may or may not be signs that it may or may not exist some time after the expansion chassis comes out, I have been following the expansion chassis project for just this reason).  However, there may be a temporary solution in the joystick >!

Keep in mind that I have never used an Atari computer (although I have run ST stuff in emulation), although I used what I think was a 7800 once, and a 2600 several times, and I saw a 400 in person once.  So Atari itself isn't really my nostalgia and I'm not necessarily trying to turn the 7800 and the proposed expansion chassis into an 800.

[GroovyBee]

What sort of graphics output does the BASIC support? You can have 1BPP on the 7800 and that'll give you 40 x 24 display. However if you use the higher colour modes you'll drop to a 20 x 24 display. Do you need text/arbitrary lines on screen at the same time?

[The Usotsuki]

GroovyBee, on Mon Oct 25, 2010 5:31 AM, said:

What sort of graphics output does the BASIC support? You can have 1BPP on the 7800 and that'll give you 40 x 24 display. However if you use the higher colour modes you'll drop to a 20 x 24 display. Do you need text/arbitrary lines on screen at the same time?

My intention was that I wanted to make something simple like Commodore BASIC, i.e., no graphics stuff at first.  A plain PET-style 40x24/monochrome mode is perfectly sufficient.

I'd probably be porting EHBASIC first, as soon as the capabilities exist.  Of course, I can't release that in any form except download (due partially to the license, and partially to it being too similar to M$ BASIC *under* the hood), so I'll need to write another BASIC, which quickly puts me back out of my league - but writing a kernel for BASIC to sit on is something I can do and have done (I wrote one for a virtual not-quite-PET that I designed and another for the Apple ][).

[GroovyBee]

The Usotsuki, on Mon Oct 25, 2010 8:25 AM, said:

My intention was that I wanted to make something simple like Commodore BASIC, i.e., no graphics stuff at first.  A plain PET-style 40x24/monochrome mode is perfectly sufficient.

Do you need graphics with that monochrome display or just text? Basically I'm trying to gauge how much RAM you need. If you don't need graphics then you can dispense with a linear video frame buffer and it might work on a stock machine for small programs (handling I/O would be a different side to the project altogether). How much working RAM do you need?

What assembler are you using?

[The Usotsuki]

GroovyBee, on Mon Oct 25, 2010 8:35 AM, said:

Do you need graphics with that monochrome display or just text? Basically I'm trying to gauge how much RAM you need. If you don't need graphics then you can dispense with a linear video frame buffer and it might work on a stock machine for small programs (handling I/O would be a different side to the project altogether). How much working RAM do you need?

I don't need graphics.

Quote

What assembler are you using?

CA65.  It's the one I'm most familiar with.

[GroovyBee]

OK. Have you downloaded the documentation for MARIA?

[The Usotsuki]

Hm, I got 3 files gcc1702b_maria_specs.pdf, MARIA_01.txt and DLLTemplate.ZIP

[GroovyBee]

Sounds like you are good to go on a stock machine then.

[The Usotsuki]

I think so too, for the output routines at least.  Which is why I figured I should start with that. xD

[The Usotsuki]

With Mord's help I been trying to slog through the documentation to try to implement some sort of hello world thingy on the 7800.  Haven't figured out what format this thing wants for DLs/DLLs yet (I sometimes get confused if things aren't VERY specific).

[GroovyBee]

For a simple text display it'd be easiest to copy the DLL and DL from ROM into RAM.

[The Usotsuki]

GroovyBee, on Thu Oct 28, 2010 1:06 PM, said:

For a simple text display it'd be easiest to copy the DLL and DL from ROM into RAM.

Agreed.

The source code I have right now doesn't do anything, but I reserved a space for a DLL and DLs immediately following the font description (it contains nothing right now because I haven't figured out what to put there).

So far all I have is "reset the stack, init the tty, infinite loop", with "init the tty" nowhere near done.  But it's a start.  Space for the ROM signature is reserved and the three 6502 vectors are assigned.

Won't even *load* in MESS though.  Maybe MESS wants .A78 only?

[GroovyBee]

I'm really busy at the moment but if you can wait a couple of weeks I should be able to put together a 40 x 24 text display. However, I suspect you'll have figured it all out by then.

I don't use MESS. If you have a PC the ProSystem is probably your best bet. The big downside is that it doesn't have a debugger.

[The Usotsuki]

GroovyBee, on Thu Oct 28, 2010 1:45 PM, said:

I'm really busy at the moment but if you can wait a couple of weeks I should be able to put together a 40 x 24 text display. However, I suspect you'll have figured it all out by then.

I don't use MESS. If you have a PC the ProSystem is probably your best bet. The big downside is that it doesn't have a debugger.

Either way.  I use MESS mainly for two reasons - first that it runs natively on Linux (I already have it for Apple /// testing, I used it to write an Apple ][ loader) and second that it emulates it down to the BIOS, so that seeing the Atari logo would have assured me things worked correctly.  I have ProSystem - it desynchs the audio, which may be WINE's fault.

My Google-fu isn't finding info on A78 headers.

[Mitch]

A78 header info

/*	Header format
0	  Header version	 - 1 byte
1..16  "ATARI7800	  "  - 16 bytes
17..48 Cart title		 - 32 bytes
49..52 data length		- 4 bytes
53..54 cart type		  - 2 bytes
	bit 0 0x01 - pokey cart
	bit 1 0x02 - supercart bank switched
	bit 2 0x04 - supercart RAM at $4000
	bit 3 0x08 - additional ROM at $4000

	bit 8-15 - Special
		0 = Normal cart
		1 = Absolute (F18 Hornet)
		2 = Activision

55	 controller 1 type  - 1 byte
56	 controller 2 type  - 1 byte
	0 = None
	1 = Joystick
	2 = Light Gun
57  0 = NTSC/1 = PAL

100..127 "ACTUAL CART DATA STARTS HERE" - 28 bytes

Versions:
	Version 0: Initial release
	Version 1: Added PAL/NTSC bit. Added Special cart byte.
			   Changed 53 bit 2, added bit 3

*/

Mitch

[The Usotsuki]

Thanks.  Adding to my working code

ETA: MESS indeed was insisting on A78.  But it doesn't flash the fuji when I boot, and sign7800 and a78sign disagree on what's a valid checksum.

Edited by The Usotsuki, Thu Oct 28, 2010 10:59 PM.

[Mitch]

What size binary are you using? The emulator will probably have trouble detecting anything under 16K.
As long as the signature is valid it doesn't matter which program you use to write. There is some randomness so you won't see identical signatures every time.

Mitch

[The Usotsuki]

Mitch, on Thu Oct 28, 2010 11:08 PM, said:

What size binary are you using? The emulator will probably have trouble detecting anything under 16K.
As long as the signature is valid it doesn't matter which program you use to write. There is some randomness so you won't see identical signatures every time.

Mitch

Ah.

I was trying to intentionally limit the code as a WIP to 8K, which I felt was plenty for the job at hand.  I'll try expanding to 16K.

ETA: the new scheme I came up with is segfaulting the emu... I hope I'm doing this right :/, but there's really no code to post yet (i.e., it doesn't DO anything).

Edited by The Usotsuki, Thu Oct 28, 2010 11:35 PM.

[EricBall]

Let me see how quickly I can help you develop your text display.  I'm going to work backwards from the graphics data.  The target is a 40x25 monochrome text display using 8x8 1bpp characters.

On the 7800, graphics data is stored as follows:
1. most signficant bit is leftmost pixel
2. each line is stored on a separate page
3. the last line is stored on the first page
4. graphics data is stored on even 2K (8 line) or 4K (16 line) segments

So, for your text display, each character is made up of 8 bytes which will be stored at $F000 - $F7FF.  For example, the letter F (ascii $4F) would be:

$F04F  $00  ; ........
$F14F  $60  ; .##.....
$F24F  $60  ; .##.....
$F34F  $60  ; .##.....
$F44F  $7E  ; .#####..
$F54F  $60  ; .##.....
$F64F  $7E  ; .######.
$F74F  $00  ; ........

The 7800 supports direct sprites, where the address in the display list entry points to the graphics data, and indirect sprites (also called characters or tiles) where the address in the display list entry points to a list of indexes which are then used to address the graphics data.  For your text display we will use indirect addressing as it is then possible to create a standard memory mapped text display where each byte in memory is displayed as a single character onscreen.  The display will be stored at $2200 - $25BF (40x24 bytes).

On the 7800 a set of lines of graphics are described by a display list (stored in RAM) which is made up of display list entries.  For your text display each active line contains two 5 byte display list entries and a 2 byte display list terminator.  For example, the display lists for the first two rows of text would be:

$2600  	$00,$60,$22,$0C,$00, $14,$60,$22,$0C,$50, $00,$00
$260C	$28,$60,$22,$0C,$00, $3C,$60,$22,$0C,$50, $00,$00

The format of each 5 byte entry is: address LSB, mode byte, address msb, width, horizontal position.  So for your text display you will need 24 display lists with the correct address for the start and middle of the line.  (The width is limited to 32 characters, so each line is broken into two 20 character segments.)

Graphics processing on the 7800 starts with the display list list which is a series of 3 byte entries which point to the display list and the number of lines to use for the list.  The format of each 3 byte entry is: control byte (number of lines), address MSB, address LSB.  The display list list also contains entries for offscreen lines.  For your text display, the display list list would be:

$2780	$0F,$26,$0A, $08,$26,$0A
$2786	$27,$26,$00, $27,$26,$0C, $27,$26,$18, $27,$26,$24
$278C	$27,$26,$30, $27,$26,$3C, $27,$26,$48, $27,$26,$44
...
$27CE	$0F,$26,$0A, $09,$26,$0A

Once all of the display lists and display lists list are created in RAM, the MARIA registers are set to start the display:

$20  $00  ; BACKGRND = black
$21  $0F  ; P0C1 = white
$2C  $27  ; DPPH = LSB of display list list
$30  $80  ; DPPL = MSB of display list list
$34  $F0  ; CHARBASE = MSB of indirect graphics
$38  $00  ; OFFSET = always zero
$3C  $C3  ; CTRL = 320 1bpp, monochrome, 1 byte per character, DMA enabled

Your ROM also needs to set the following values:

$FFF8		   DC.W ROMTOP + $07FF
$FFFA	NMI	 DC.W DLLNMI
$FFFC   RESET   DC.W START
$FFFE   IRQ	 DC.W IRQRTI

Edited by EricBall, Fri Oct 29, 2010 12:19 PM.

[The Usotsuki]

EricBall, on Fri Oct 29, 2010 12:16 PM, said:

Let me see how quickly I can help you develop your text display.  I'm going to work backwards from the graphics data.  The target is a 40x25 monochrome text display using 8x8 1bpp characters.

Which is what, precisely, I was looking for. XD

EricBall, on Fri Oct 29, 2010 12:16 PM, said:

On the 7800, graphics data is stored as follows:
1. most signficant bit is leftmost pixel
2. each line is stored on a separate page
3. the last line is stored on the first page
4. graphics data is stored on even 2K (8 line) or 4K (16 line) segments

So, for your text display, each character is made up of 8 bytes which will be stored at $F000 - $F7FF.  For example, the letter F (ascii $4F) would be:

$F04F  $00  ; ........
$F14F  $60  ; .##.....
$F24F  $60  ; .##.....
$F34F  $60  ; .##.....
$F44F  $7E  ; .#####..
$F54F  $60  ; .##.....
$F64F  $7E  ; .######.
$F74F  $00  ; ........

In other words I got more or less the right idea from Mord but I stored my font upside-down. x.x  I can easily fix that.  My master font is stored in the 6845 format.

EricBall, on Fri Oct 29, 2010 12:16 PM, said:

Graphics processing on the 7800 starts with the display list list which is a series of 3 byte entries which point to the display list and the number of lines to use for the list.  The format of each 3 byte entry is: control byte (number of lines), address MSB, address LSB.  The display list list also contains entries for offscreen lines.  For your text display, the display list list would be:

$2780	$0F,$26,$0A, $08,$26,$0A
$2786	$27,$26,$00, $27,$26,$0C, $27,$26,$18, $27,$26,$24
$278C	$27,$26,$30, $27,$26,$3C, $27,$26,$48, $27,$26,$44
...
$27CE	$0F,$26,$0A, $09,$26,$0A

Once all of the display lists and display lists list are created in RAM, the MARIA registers are set to start the display:

$20  $00  ; BACKGRND = black
$21  $0F  ; P0C1 = white
$2C  $27  ; DPPH = LSB of display list list
$30  $80  ; DPPL = MSB of display list list
$34  $F0  ; CHARBASE = MSB of indirect graphics
$38  $00  ; OFFSET = always zero
$3C  $C3  ; CTRL = 320 1bpp, monochrome, 1 byte per character, DMA enabled

Your ROM also needs to set the following values:

$FFF8		   DC.W ROMTOP + $07FF
$FFFA	NMI	 DC.W DLLNMI
$FFFC   RESET   DC.W START
$FFFE   IRQ	 DC.W IRQRTI

Yeah, I found out about that much.

		  .org	  $C000
A78adr	 =		*
font:	 .incbin   "ataruso.78f"

nmi:
irq:	  rti

		  .res	  $FFF8-*, 0
		  .byte	 $FF
		  .byte	 ($07+>A78adr)
vnmi:	 .word	 nmi
vrst:	 .word	 reset
virq:	 .word	 irq

This is actually almost the entire code I have so far .  (I'm using the CA65 assembler which I already use for my Apple projects, so it's a bit different than what you're used to but I can still understand the dialect you're using.)

[The Usotsuki]

Some evidence I do know, more or less, what I'm doing about TTY drivers is - it's not the latest most fixed version, I can't find that since my drive crashed - I wrote a firmware for the Apple ][+ that works reasonably well (apart from needing 65C02 and being a rat's nest).

http://usotsuki.info/gameware.lst

I'm not likely to be going to use much of this code though.

[Harry_Dodgson]

Hi,

Hmm... text ouput using Atari 400 font.  Sounds like what I did for the 7800 Monitor cartridge.  It wasn't that hard to convert.

Harry

[The Usotsuki]

Monitor, as in debugger?

[The Usotsuki]

I'm working on some relatively generic/reconfigurable 6502 terminal code that will be of use once I know enough to work the 7800.  It'll take some time (though I am working from existing code of mine, that code is 65C02, which won't work on a 7800).