The Usotsuki Posted October 24, 2010 Share Posted October 24, 2010 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.) Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 25, 2010 Author Share Posted October 25, 2010 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 25, 2010 Share Posted October 25, 2010 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? Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 25, 2010 Author Share Posted October 25, 2010 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 ][). Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 25, 2010 Share Posted October 25, 2010 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? Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 25, 2010 Author Share Posted October 25, 2010 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. What assembler are you using?CA65. It's the one I'm most familiar with. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 25, 2010 Share Posted October 25, 2010 OK. Have you downloaded the documentation for MARIA? Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 25, 2010 Author Share Posted October 25, 2010 Hm, I got 3 files gcc1702b_maria_specs.pdf, MARIA_01.txt and DLLTemplate.ZIP Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 25, 2010 Share Posted October 25, 2010 Sounds like you are good to go on a stock machine then. Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 25, 2010 Author Share Posted October 25, 2010 I think so too, for the output routines at least. Which is why I figured I should start with that. xD Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 28, 2010 Author Share Posted October 28, 2010 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). Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 28, 2010 Share Posted October 28, 2010 For a simple text display it'd be easiest to copy the DLL and DL from ROM into RAM. Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 28, 2010 Author Share Posted October 28, 2010 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? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 28, 2010 Share Posted October 28, 2010 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. Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 28, 2010 Author Share Posted October 28, 2010 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. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted October 29, 2010 Share Posted October 29, 2010 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 Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 29, 2010 Author Share Posted October 29, 2010 (edited) 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 October 29, 2010 by The Usotsuki Quote Link to comment Share on other sites More sharing options...
+Mitch Posted October 29, 2010 Share Posted October 29, 2010 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 Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 29, 2010 Author Share Posted October 29, 2010 (edited) 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 October 29, 2010 by The Usotsuki Quote Link to comment Share on other sites More sharing options...
EricBall Posted October 29, 2010 Share Posted October 29, 2010 (edited) 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 October 29, 2010 by EricBall Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted October 29, 2010 Author Share Posted October 29, 2010 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 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. 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.) Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted November 4, 2010 Author Share Posted November 4, 2010 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. Quote Link to comment Share on other sites More sharing options...
Harry_Dodgson Posted November 5, 2010 Share Posted November 5, 2010 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 Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted November 5, 2010 Author Share Posted November 5, 2010 Monitor, as in debugger? Quote Link to comment Share on other sites More sharing options...
The Usotsuki Posted November 11, 2010 Author Share Posted November 11, 2010 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). Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.