Jump to content
IGNORED

My Atari XEGS Project


boisy

Recommended Posts

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Rybags
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...