boisy Posted February 21, 2012 Author Share Posted February 21, 2012 First off - do you have a rough guestimate of what the board will cost and how many internal modifications to the machine would be needed? I'm tempted to jump into this thing. Gary's putting together the design which will have a socket for the 6809 and 6502 and a jumper to activate one while deactivating the other. We'll go through PCBExpress and make four prototype boards as "seed boards" with the idea of getting them into the hands of creative folk who can actually do something with them. If interest is high enough (and I believe it is), we'll make a larger run with a different board house. I'll assemble these four boards myself and test them. I'll keep one and sell the other three for around $100 each. I'm not trying to make money on these initial prototypes, but I won't give them away either. John Linville has already asked for one. If you want one of the two remaining, let me know. Given your knowledge of the Atari and your technical acumen, I expect you are someone who would really exploit the Liber809. Also, I've only tested this on the XEGS. I would love to see how this works on other A8 systems and you could probably do that. Internal modifications to the XEGS have been minimal. Assuming the 6502C and the ROM are soldered onto the board, you need to carefully desolder them and put in their place 40 and 28 pin sockets. I did this successfully on my XEGS, and managed to lift only a couple of traces off the board, which I carefully placed back. That's it. No wires, no cut traces. The only other consideration is that you'll need ROM burner. Right now NitrOS-9 is being loaded directly into ROM, but I expect a better route will be to write SIO routines in 6809 assembly that will load the OS from a server. Screen - no, you can start it anywhere, the Antic hardware only has 12 bits as counter though, so crossing a 4K boundary wraps around to the start of the 4K. You need a second LMS ($4x) type instruction in the DList to cross the 4K. It's generally only an issue in the hires modes that use more than 4K. Ok. I'll have to steal some low memory in the memory map for the screen. Shouldn't be too difficult. OS size - it's actually 14K not 16. The 2K that would otherwise appear in the IO space gets mapped to $5000. Atari uses this 2K for the Self Test routines which essentially run as a standalone and coldstart the machine when you exit. But, the Basic/Missile Command ROM mapping is contiguous with the OS, ie $A000 - $BFFF = Basic ROM, $C000 - $CFFF = low portion of OS ROM. I'd suggest use the Missile Command slot if you need more than 14K. That way if you have a dual CPU machine, the Atari side only loses the game, Basic is ultimately more useful. The problem though in using that extra ROM is that it's only present on the one chip on XEGS machines. The remainder of the XL/XE machines have Basic on it's own 8K chip. All other XL/XE have the OS on single 16K chip, except 1200XL which has it on 2 8K chips. Noted. For now I'm cramming the entire OS into the area between $E000-$FFFF. It fits so far, but it's going to get real tight real quick. The VBlank is near enough to 60 FPS NTSC, 50 for PAL. In reality it's slightly less, but sufficient to maintain a clock that runs 0.5% or so slower than it should. Perfect. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 21, 2012 Share Posted February 21, 2012 I might hold off for a subsequent run. No Eprom burner here, it's something I've been thinking about buying though. What would be nice is if we can convince phaeron to add 6809 emulation to Altirra. That'd save anyone developing a whole lot of time. 1 Quote Link to comment Share on other sites More sharing options...
potatohead Posted February 21, 2012 Share Posted February 21, 2012 I would definitely be interested in the second run. Dropping 6809 CPUs into a few classic machines is really intriguing. Emulator support is seconded. I would start to take advantage of that long before any real hardware would be needed. I suspect others would do the same. The current OS makes a lot of sense, but... I'm wondering, if there are other options possible, so that a server isn't needed. It's early for that discussion, but I thought I would toss it out there. 6809 is such a fun chip to program too! That's the most intriguing part to me. For now, watching with great interest! Quote Link to comment Share on other sites More sharing options...
random_rodder Posted February 21, 2012 Share Posted February 21, 2012 Boisy, You know know I've been a fan and customer of Cloud9 for a few years. This project is just one reason why - C9's drive to bring the coolest wares to the CoCo community and now to others. Kudos!!! Brian Quote Link to comment Share on other sites More sharing options...
boisy Posted February 22, 2012 Author Share Posted February 22, 2012 Thanks Brian. NitrOS-9 is now booting up and the video console driver is working. Check out the latest blog post at http://liber809.blogspot.com/ 2 Quote Link to comment Share on other sites More sharing options...
sloopy Posted February 22, 2012 Share Posted February 22, 2012 Looks nice... very nice :') woot! my name in pixels! all I did was make sure the colors were correct... wouldnt be good to use anything but the 'correct' Atari blue :'D sloopy. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2012 Share Posted February 22, 2012 Matter of opinion that one... my preference would be $82 for background and bump foreground by +2 luma. Quote Link to comment Share on other sites More sharing options...
sloopy Posted February 22, 2012 Share Posted February 22, 2012 Well sure, $CA and $94 arnt my personal choice either... but its only fitting the stock colors are kept... only seems right, and its not like it cant be changed for personal pref's ;') sloopy. Quote Link to comment Share on other sites More sharing options...
JamesD Posted February 22, 2012 Share Posted February 22, 2012 Pretty cool Boisy! Quote Link to comment Share on other sites More sharing options...
boisy Posted February 22, 2012 Author Share Posted February 22, 2012 Well sure, $CA and $94 arnt my personal choice either... but its only fitting the stock colors are kept... only seems right, and its not like it cant be changed for personal pref's ;') sloopy. The CoCo 3 display driver allows you to change the background, border or text color by using escape codes. So for example, writing $1B $32 $04 would change the foreground color to whatever $04 represented. The background color would be changed with $1B $33 $09, etc. A similar method could be done in this driver. The CoCo 3 allowed individual characters to have their own foreground and background color, though. It seems that it's all or none on the Atari, correct? Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2012 Share Posted February 22, 2012 In hires, you're stuck with 1 colour and 2 luma variants of that. Ways around it - use multicolour text mode but lose half the resolution - 4 pixel wide characters somewhat suck in an editing environment. - Use Player/Missile underlays. Set them all to the same colour, gives you 2 alternate background choices. But it comes with a memory loss of about 768 bytes or can be done with less memory use but a fair chunk of CPU by using DLIs. - Use DLIs to provide a seperate colour and pair of luma values per row of text. Quote Link to comment Share on other sites More sharing options...
boisy Posted February 22, 2012 Author Share Posted February 22, 2012 Just added another post on the Liber809 blog. Mdir output confirms placement of the modules in ROM (with photo!) Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2012 Share Posted February 22, 2012 You can put a direct link in your tagline if you want to save people digging it out (it's somewhere in the forum profile menus here) I've added the blog to my bookmarks. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2012 Share Posted February 22, 2012 Do you have any I/O stuff done besides screen ? Keyboard would probably be a nice easy one to start with - one advantage of the Atari hardware is that Pokey already does most of the work. No software keyscan, you just read the code and can translate to Ascii with a table lookup. Quote Link to comment Share on other sites More sharing options...
boisy Posted February 22, 2012 Author Share Posted February 22, 2012 Do you have any I/O stuff done besides screen ? Keyboard would probably be a nice easy one to start with - one advantage of the Atari hardware is that Pokey already does most of the work. No software keyscan, you just read the code and can translate to Ascii with a table lookup. I plan on tackling the keyboard next. Can the POKEY generate an IRQ when a character from the keyboard is ready? That would be ideal way to get characters. There's also the ROM space issue. I barely have any room left at $D800-$FFFF and could use the space from $C000-$CFFF. The hole at $D000-$D7FF makes building a boot ROM "interesting" shall we say. It means I'll have to align modules so that they exist around that area, and modify the kernel's module searching routine to also compensate for that hole. By the way, I presume that the ROM space at $D000-$D7FF is just dead, right? There's no way to get to it? Not that it matters... I also need to get a clock driver going so that we can have multitasking. I'm thinking the clock will hang off of the NMI. After that I need to explore either SIO or DriveWire. I'm thinking the latter because we have a Java based server (http://sites.google.com/site/drivewire4/) that handles networking and other features in NitrOS-9 that can be added at some point. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2012 Share Posted February 22, 2012 (edited) The ROM that would otherwise appear at $D000 - $D7FF is the 2K Self-Test. On all XL/XE it exists and is swapped in occupying $5000-$57FF by setting PIA PORTB bit 7 to 0 (note, it only swaps in if the OS ROM is also swapped in). That's probably not real convenient for you, but you could use it e.g. for one-time stuff like initial powerup routines, or maybe just use it for seldom used stuff. Keyboard - by default the OS uses the keyboard IRQ. It's entirely possible to not use it but you'd end up with more code. IRQ is only generated for key down, there's no key up or repeat condition, that has to be handled by software. Another important thing is debounce. Without a debounce algorithm, you get occasional extra keypresses recognised when a key is released. On Atari debouce is handled with a software timer. Debounce is recognised if the same keycode is seen by the IRQ within 3 VBlank times (I think that's right). Keyboard IRQ sets the timer, the VBlank routine decrements it if it's nonzero. Keyboard IRQ checks if the timer is nonzero. If it is, and the "current" key value is same as previous, then it's ignored. Key repeat is handled mostly by the VBlank. Do you have any Atari OS source code or reverse-engineered source ? Having that can help. Also there's a keyboard table in ROM. IIRC it's 192 bytes long. You could in theory get by with just a 64 byte table. Just how versatile you want your keyboard and editor handling to be would be a deciding factor. BREAK key has it's own IRQ. Console keys Start/Select/Option go to individual port bits on GTIA. No IRQ for these keys. RESET key is a hardware reset. No masking or otherwise disabling on XL/XE. Reset on 400/800 generates an NMI. SIO - here's where it gets interesting. Some software does it - you can setup SIO to do most of it's work in the background. Atari OS just uses IRQs and has the CPU loop while an operation takes place. But one consideration - you'd probably want to use existing Atari peripherals and modern-day emulated devices. Keeping it close to spec might be advisable. Although you could support the turbo modes later on. Edited February 22, 2012 by Rybags Quote Link to comment Share on other sites More sharing options...
boisy Posted February 23, 2012 Author Share Posted February 23, 2012 Rybags, I'll have to think what that extra 2K could be used for. For now I'll leave it be. I have the keyboard working using the POKEY IRQ. The IRQ is routed through NitrOS-9's IRQ Polling routine which is managed by IOMan. I do have the Atari OS source and lifted the key code table from there to place into VTIO. The interrupt service routine in VTIO does circular buffer management and is being called per key press. Works great. I understand from the IRC guys that some keys are different. Carriage return is $9B for instance, instead of $0D. NitrOS-9 can accommodate those mappings easily in the device descriptor, or I can modify the key code table in the driver to just send an $0D when the return key code issued. VTIO needs a little firming up. After that I need to revisit the clock for some tidy up, then I'll start looking at SIO. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2012 Share Posted February 23, 2012 Are you using the XL keyboard IRQ stuff ? There's a lot of unecessary stuff they left in for the Function keys for the 1200XL which can be gotten rid of. But I guess so long as it's reasonably trim and debounce & repeat work for you, it should be all good. Most of the keyboard map/translating is done within the K: and E: handlers. I'm not sure if you want to duplicate parts of those. They're somewhat closer to the application layer in the scheme of things, where the IRQ handler is closer to the hardware. Quote Link to comment Share on other sites More sharing options...
boisy Posted February 23, 2012 Author Share Posted February 23, 2012 Are you using the XL keyboard IRQ stuff ? There's a lot of unecessary stuff they left in for the Function keys for the 1200XL which can be gotten rid of. But I guess so long as it's reasonably trim and debounce & repeat work for you, it should be all good. Most of the keyboard map/translating is done within the K: and E: handlers. I'm not sure if you want to duplicate parts of those. They're somewhat closer to the application layer in the scheme of things, where the IRQ handler is closer to the hardware. Well, I am not doing a code for code translation. I wrote my own code to setup the keyboard IRQ and pull the key from the table. From there it's a bit of boilerplate code for what OS-9 wants. I did not done any debounce or repeating yet. Funny enough, the keyboard seems to not emit duplicate chars. Not sure why. It's not the best keyboard either. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2012 Share Posted February 23, 2012 Spongy POC actually. Could be why it sort of does it's own debounce. I've done keyboard stuff with other models without debounce and it's been prevelant. Probably part of the reason the translation occurs later down the line - easier to use raw keycodes in the IRQ and VBI code rather than table lookup in both cases (plus some keys + Shift translate to the same thing). You should have some fun with SIO. I don't know much about the target OS but in theory you could perform SIO as a background operation, kind of like the Amiga. Quote Link to comment Share on other sites More sharing options...
boisy Posted February 23, 2012 Author Share Posted February 23, 2012 The SIO looks easy enough. One interrupt per character, incoming and outgoing. What isn't clear is if the outgoing serial interrupt is sent BEFORE the character is written (as in a "hey I'm ready for a character"interrupt) or is asserted AFTER the character has been successfully transmitted. There are a few minor bugs in the VTIO driver that I want to get fixed before I move on. Also, I spent some time last night trying to address the instability of the prototype. I think taking it in and out of the socket has made it less reliable. I reran the soldering iron over a couple of suspect traces, and it's performing better. All the more reason to get proper prototype boards made, which should be happening next week. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2012 Share Posted February 23, 2012 There's 2 IRQs for sending, "Output Needed" and "Output Complete". Seron - when a byte starts transmitting the next one becomes "needed" right away, the early IRQ helps ensure no gap in transmission. Seroc - in the normal course of events, shouldn't occur. Transmission is complete but no new data ready to go out. Generally you manually stuff the first byte of a record, then enable the IRQs which can then take care of the remainder. Without looking, I think the OS actually uses the same routine to handle Seron/Seroc. In theory you could do the entire record from IRQs, enabling SEROC when no serial transmission is occurring generates a sort of "IRQ on demand", so it could send the first byte for you, then Seron handles the rest. Checksums - the formula is to start with 00, then add each byte to the checksum then add the carry back in again. This guarantees that the only time a 00 checksum is generated is if the entire record is zeros. With IRQ handling - to acknowledge an IRQ you disable it, then re-enable it. You need to keep a "shadow" of IRQEN in RAM because the IRQEN register is write-only, reading it fetches IRQST which is the "status" of Pokey's IRQs. Generally you re-enable the relevant serial IRQ except when you know there's no more data to go out. SIO Command line - that's handled by PIA. The OS manual has the timings in milliseconds of what the expected delays are, that'll help you remain within specs for standard peripherals. Serial Mode/bitrate - handled by SKCTL and the audio part of Pokey. The hardware manual and OS source should come in handy there. You probably already know it, but of course note that the Atari serial port is just normal logic levels, not the +-12 Volts used by RS232. A homebrewed SIO2PC interface is probably a good idea. $6 or so worth of IC, capacitor & resistor and a couple of square inches of PC board. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2012 Share Posted February 23, 2012 Should also have mentioned: it is possible to do serial transmission entirely in "polled mode". This is where you enable the IRQs on Pokey but disable them from the CPU side. Then just sit in a wait loop and manually reset/set the enable bits in IRQEN as each byte goes in or out. Some fast-loader systems use this since very high bitrates can be too quick for the overhead of IRQ routines. You might prefer to use polled mode during development, it might be easier to debug. Quote Link to comment Share on other sites More sharing options...
boisy Posted February 23, 2012 Author Share Posted February 23, 2012 Should also have mentioned: it is possible to do serial transmission entirely in "polled mode". This is where you enable the IRQs on Pokey but disable them from the CPU side. Then just sit in a wait loop and manually reset/set the enable bits in IRQEN as each byte goes in or out. Some fast-loader systems use this since very high bitrates can be too quick for the overhead of IRQ routines. You might prefer to use polled mode during development, it might be easier to debug. This does sound simpler to start with... but you're saying that you need to enable IRQs on POKEY just to do polled I/O, and mask interrupts on the CPU? Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 24, 2012 Share Posted February 24, 2012 That's right. There's actually 4 ways to do SIO on the Atari: 1. Conventional via IRQ routines with mainline code sitting in a wait loop. 2. Mask IRQs at CPU (SEI) and mainline code waits on Pokey IRQST flags and branches out to read input or supply more output when needed. Used by some high speed I/O routines. 3. Automated approach where almost everything is done via interrupts, allowing mainline code to continue execution. Used by Lucasfilm disk games. 4. "Bit Banging". Serial output can be controlled manually without using serial shift register. No usage that I know of. Serial input can be read directly without using shift register. This is used by the cassette routines to adjust bitrate to cater for variable tape speed, stretched tape etc. Quote Link to comment Share on other sites More sharing options...
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.