267 replies to this topic

[boisy]

Rybags, on Thu Feb 23, 2012 12:33 PM, said:

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.

Ok, I've starting to tackle the SIO late this afternoon.  I figured I would do a simple DriveWire printer driver.  Easy enough.  I've got sloopy's SIO adapter plugged in and the USB port selected on my Mac.



Early in VTIO initialization I do this:


   lda    #$03
   sta    SKCTL

In my printer driver, I am initializing the baud rate to 38,400bps (note I'm not sure if I need to byte swap this or not)


* initialize POKEY to ~38.4K
   ldd    #$1000
*    exg    a,b
   std    AUDF3



In my printer driver's write routine I'm masking interrupts, loading the shadow register (which has the two high bits set by VTIO for keyboard and break).  I am setting the "serial output done" interrupt bit, then writing the character in A to the SEROUT.

I'm then looping, reading the IRQ status until the "serial output done" interrupt status bit is cleared (meaning the interrupt has fired), then rewriting the shadow register to the real register to clear that interrupt.


Write
  pshs   cc
  orcc   #IntMasks
  ldb    D.IRQENSHDW
  orb    #%00001000
  stb    IRQEN
  sta    SEROUT
loop@
  ldb    IRQST
  bitb   #%00001000
  bne    loop@
  ldb    D.IRQENSHDW
  stb    IRQEN
  clrb
  puls   cc,pc




The end result: no characters show up on my terminal window and the keyboard is dead after this.  I cannot type anything.

Any ideas?

Edited by boisy, Fri Feb 24, 2012 3:48 PM.

[boisy]

An update....

The IRC guys pointed me to something that I was missing.  I needed to set the clock up.  So the printer driver init code looks like this:


* initialize POKEY to ~38.4K
               ldd       #$1000
*               exg       a,b
               std       AUDF3

      lda #$22
     sta SKCTL

               lda  #$28      clock ch. 3 with 1.79 MHz, ch. 4 with ch. 3
               sta  AUDCTL set audio control

And now I'm getting virtual print data to the DriveWire server at 38400 baud.

But my keyboard is still dead after using the printer.  I expect my code above is not resetting something correctly after the interrupts are cleared?

[boisy]

Ok, I've figured it out.  Putting #$23 in SKCTL gives me back the keyboard.

I'm now able to redirect output of commands to the virtual printer on the DriveWire server.

I've stretched the 14K of ROM pretty thin to the point where I cannot load the modules necessary to do disk management.  RBF is needed for that, and it comes in at 3K by itself.  It's time to get a boot loader written that brings in the bootfile from DriveWire via the SIO.

[boisy]

Alright.  I'm truly stuck and I need some help

I've got SIO working with DriveWire server on the Mac.  I can read and write bytes reliably.  Everything is cool on that.  It took some fighting but I finally figured it out.

What is stumping me now has nothing to do with SIO.  Let me explain what I'm doing.

I've hit a wall with the 14K ROM space and NitrOS-9.  The modules I want to add just won't' fit.  Plus, this isn't going to be a very usable product if people have to either burn a ROM or buy a ROM to install in their Atari every time they want to change the operating system.

So my thought was to come up with a "boot ROM" of sorts.  This boot ROM would have code that would, upon firing up the Atari, copy part of itself to low RAM (say, $4000).  This code would put the Atari in all RAM mode (by writing $FE into $D301 a.k.a. PORTB) and then use the SIO to talk to the DriveWire server and grab bytes from there and place them from $8000-$FFFF in the Atari's memory.  After that, the routine would jmp to the address held in $FFFE (the 6809 reset vector) and NitrOS-9 would run happily.

However, my tests are showing that writing $FE into $D301 only gives me ram up to $9FFF.  $A000 and above appear to be ROM, even after I write $FE into $D301.

My test goes something like this:

After copying code into low RAM at $4000, I jump to there, and then do the following:

  lda #$FE
sta $D301

  ldd #$A55A
  std $9FFE
  ldd $9FFE
  cmpd #$A55A
  bne CycleColors
xxxx jmp xxxx

The idea here is that I write 16 bits from the D register into $9FFE, then read it right back and compare what I read to what I wrote earlier.  If they're the same, it's RAM and the computer just sits in a tight loop.  If not, it's ROM, and the computer cycles through colors on the screen ad nauseum.

The above code causes the computer to sit tight.  But if I change $9FFE to $A000, $B000, $C000, $D000, $E000 or $F000, I get colors cycling.

I've looked at this 4 or 5 different ways and am coming to the conclusion that writing $FE to $D301, at least on my Atari XEGS here in my shop, does NOT give me access to RAM from $A000-$FFFF, which is what I understood the case to be from the good folks on the IRC channel and from what I read on this link:  http://www.atariarch....  Specifically it says about $D301 bit 0:

You can disable the ROM between 49152-53247 ($C000-$CFFF) and 55296-65535 ($D800-$FFFF) by setting bit 0 to 0 (the ROM area becomes RAM; note that the area between $D000 and $D7FF remains intact). However, unless another OS has been provided, the system will crash at the next interrupt (1/60 sec- ond later!), so you need to disable the interrupts first.


That is not what I am seeing with my tests.  I would really appreciate knowing what is going on and why.  Any insights from the gurus?

[andym00]

You need to setup PBCTL ($D303) before you can just use it.. I guess the Kernel leaves it normally set up..

; Turn off all ROMs..
lda #$38
sta PBCTL
lda #$FF
sta PORTB
lda #$3C
sta PBCTL
lda #$FE
sta PORTB

I think..

[bob1200xl]

Isn't there an internal cart in $A000? You need to set $D301 to $FC, I think...

That will give you RAM all the way up to $BFFF.



Bob

[boisy]

andym00, on Sat Feb 25, 2012 2:31 PM, said:

You need to setup PBCTL ($D303) before you can just use it.. I guess the Kernel leaves it normally set up..

; Turn off all ROMs..
lda #$38
sta PBCTL
lda #$FF
sta PORTB
lda #$3C
sta PBCTL
lda #$FE
sta PORTB

I think..

andym00, on Sat Feb 25, 2012 2:31 PM, said:

You need to setup PBCTL ($D303) before you can just use it.. I guess the Kernel leaves it normally set up..

; Turn off all ROMs..
lda #$38
sta PBCTL
lda #$FF
sta PORTB
lda #$3C
sta PBCTL
lda #$FE
sta PORTB

I think..

You were right.  Thanks.  That was exactly the problem.

I'm now booting NitrOS-9 using DriveWire over SIO!  This is great, because it frees me from the limitation of the ROM size.  

Thanks for the hint.

[Rybags]

You could have used ROM from $A000-$BFFF to give more contiguous space but then you have a situation where non-XEGS machines would have to replace a second ROM chip.

Default setup of the PIA Port bits is input and $FF on outputs, so yes, you'd need to set up the data direction first (all output PortB) then set PortB.

I'd suggest look at the ATR format for disk images.  Using standard disk sizes would then allow you to use real peripherals and/or the standard disk emulation packages on the PC side of things.
Of course you'd also need to do your SIO stuff like Atari does it, which would be a fair amount of work.

[boisy]

Rybags, on Sat Feb 25, 2012 8:16 PM, said:

You could have used ROM from $A000-$BFFF to give more contiguous space but then you have a situation where non-XEGS machines would have to replace a second ROM chip.

It appears that the XEGS is somewhat of an outlier in the mix of XL/XE configurations.  Is that accurate?  Which XL/XE should I get that would be more representative of what people are using?

Rybags, on Sat Feb 25, 2012 8:16 PM, said:

Default setup of the PIA Port bits is input and $FF on outputs, so yes, you'd need to set up the data direction first (all output PortB) then set PortB.

I'd suggest look at the ATR format for disk images.  Using standard disk sizes would then allow you to use real peripherals and/or the standard disk emulation packages on the PC side of things.
Of course you'd also need to do your SIO stuff like Atari does it, which would be a fair amount of work.

I am hoping to enlist the help others more knowledgable than I to support those formats.   My choosing DriveWire for the initial bootstrap as for expediency and because I was very familiar with the existing code base.  It's also already written in 6809 assembly which made bringing it up a lot quicker   But for wider acceptance, it would be beneficial to support formats familiar with Atari users.

There is another software project on the CoCo side that I'm eyeing for a possible.  It's called CoCoBoot, and it's a Forth interpreter that is used to bootstrap a CoCo into NitrOS-9 or some other O.S.  I believe this will expedite the creation of a boot ROM that can be used to bootstrap the Liber809.   Of course, with that project possibly coming to the Atari, it will probably need a name change.

[Rybags]

The XEGS is unique in that there's the single 32K ROM for everything onboard.

All other XL and XE except 1200XL have a 16K OS ROM and 8K Basic ROM.

Another thing I was meaning to ask - will you be having a ROM board as well since the OS also needs to be switched?

The OS manual has some rudimentary SIO stuff like the flow of command and Ack, Complete and Data frames.
Implementing SIO so you can do the basic read, write, status, format commands shouldn't be too much work.

Another consideration with your board design is that the physical layout of every machine is different.  What fits in an XEGS mightn't necessarily work with other machines.  XEGS gives you a nice amount of clearance due to not having the keyboard built in, but other machines don't have that luxury.
Most should have decent clearance over the OS Rom but not necessarily the case for the CPU.

[boisy]

Rybags, on Sat Feb 25, 2012 9:58 PM, said:

The XEGS is unique in that there's the single 32K ROM for everything onboard.

All other XL and XE except 1200XL have a 16K OS ROM and 8K Basic ROM.

CoCoBoot fits easily in 16K, so it should be fine for these types of systems.

Rybags, on Sat Feb 25, 2012 9:58 PM, said:

Another thing I was meaning to ask - will you be having a ROM board as well since the OS also needs to be switched?

It's an idea.  I can see having a dual ROM daughterboard that would let you jumper between the 6502 and the 6809 ROM.

Actually it's enough of a convenience that I'm wondering if something like that might not already exist for swapping common EPROM types?

Rybags, on Sat Feb 25, 2012 9:58 PM, said:

The OS manual has some rudimentary SIO stuff like the flow of command and Ack, Complete and Data frames.
Implementing SIO so you can do the basic read, write, status, format commands shouldn't be too much work.

I have the 6502 source to the Atari OS ROMs, so you're right.  Getting that translated would not be difficult.

Rybags, on Sat Feb 25, 2012 9:58 PM, said:

Another consideration with your board design is that the physical layout of every machine is different.  What fits in an XEGS mightn't necessarily work with other machines.  XEGS gives you a nice amount of clearance due to not having the keyboard built in, but other machines don't have that luxury.
Most should have decent clearance over the OS Rom but not necessarily the case for the CPU.

And that's why I would like to get a few more systems for testing this out on.  The prototype run of the Liber809 is not going to be ideal or optimal in size because the board house insisted we get a specific size.  It will fit in the XEGS as laid out, but may not for others.  Again, we're planning for a larger run once we've nailed down the design, and then we'll concentrate on optimization.

[boisy]

Just a follow-up to my last post.  I found an EPROM switcher here:  http://vic-20.de/x15...dware/2364.html

Looks like it's small enough to fit the bill.  You could use a single 27C512 and switch between the upper and lower 32K banks.  One 32K bank would have the XEGS ROM, the other would have the Liber809 environment.

[Rybags]

These days we have upgrades like Atarimax 32in1 OS and Ultimate 1 Meg which use modern flash tech and can house multiple OSes.

People have also put larger EPROM sizes in and used switching.

For Atarimax 32in1, I actually wrote a bit of software that communicates with the onboard PIC to switch OSes.
Ultimate 1 Meg, possibly something could be done.

I'd assume that Atari people wanting your upgrade would start out with a stock machine.  So the best OS option will probably be the cheapest one, ie homebrew hard switchable Eprom.

Edited by Rybags, Sat Feb 25, 2012 10:40 PM.

[rdemming]

It is interesting to see the progress in this project.

I suppose 16Kb ROM is little for an OS like this. But since you are already "Frankensteining" the Atari with a 8909 processor, you could replace the OS rom with something that adds some back-switching logic to extend the available OS ROM space. You then can use for example a 29F040 flash so you have 512Kb available as OS space. But of course the bank-switching makes it more complicated to build an OS. As Rybags already wrote, the AtariMax 32-in-1 supports run-time switching of the OS bank, so this could also be used for a bank-switched OS.

I'm wondering if an 68008 could also be an option as replacement CPU. That has also an 8-bit data bus but with the benefit of extra address lines (allowing for linear memory range of 1MB or 4MB depending on the variant) and a 32-bit instruction set. But the problem with the 68008 will be that the boot-up run and stack address are stored at address $0-7, so you should map the boot rom to these address as well.

Robert

[Rybags]

32in1 can't switch on the fly, the PIC resets the machine when you request a switch.  Although that could be gotten around by removing the connection but then manual intervention would be needed when switching OSes normally.

An Atarimax flashcart might be worth looking into.  Then you have 128K or 1 Meg worth of ROM in 8K chunks @ $A000 and can switch it out altogether.
But that adds to the overall budget although they're pretty cheap if you buy in bulk.

[sloopy]

Over engineering a simple task... a simple 2-1 OS switch, have the switch line with a pull-up/pull-down as needed, and have a line from the Liber809 board come over that switches the OS ROM for the active CPU...

sloopy.

[rdemming]

Rybags, on Sun Feb 26, 2012 7:20 AM, said:

32in1 can't switch on the fly, the PIC resets the machine when you request a switch.

Ooops, I thought the AtariMax 32-in-1 could switch banks without a reset.

sloopy, on Sun Feb 26, 2012 7:27 AM, said:

Over engineering a simple task... a simple 2-1 OS switch, have the switch line with a pull-up/pull-down as needed, and have a line from the Liber809 board come over that switches the OS ROM for the active CPU...

The software bank-switched OS idea is not to switch between two different OSes, but to provide more ROM space for a single OS (the Nitro OS). So instead of 16KB ROM for the Nitro OS, you can have multiple 16KB banks for the same OS. But as Rybags already stated, you could use a MaxFlash cartridge too to extend the available ROM space for the Nitro OS.
But since you have to replace the OS chip anyway to boot with a 6809, why not replace it with something that provides more than 16KB ROM space for a single OS.

Robert

[sloopy]

rdemming, on Sun Feb 26, 2012 8:51 AM, said:

sloopy, on Sun Feb 26, 2012 7:27 AM, said:

Over engineering a simple task... a simple 2-1 OS switch, have the switch line with a pull-up/pull-down as needed, and have a line from the Liber809 board come over that switches the OS ROM for the active CPU...

The software bank-switched OS idea is not to switch between two different OSes, but to provide more ROM space for a single OS (the Nitro OS). So instead of 16KB ROM for the Nitro OS, you can have multiple 16KB banks for the same OS. But as Rybags already stated, you could use a MaxFlash cartridge too to extend the available ROM space for the Nitro OS.
But since you have to replace the OS chip anyway to boot with a 6809, why not replace it with something that provides more than 16KB ROM space for a single OS.

Robert

Thing is, altho he is running out of room in the OS ROM, this is just for intial debug/development of the hardware, his intention was never to have the full NitrOS-9 in ROM for release... Just like Atari DOS is not in ROM (SDX excluded)...

He can go two ways with this...
1)have minimal bring up and boot capability in the ROM, and the rest in RAM (similar to a modern PC)

2)Have minimal bring up and boot capability with common system routines in ROM, and the rest of the OS in ROM (as Atari OS/DOS is done)

Which way Boisy goes is up to him, but I would guess he would go with the first, as the machineand OS he is coming from and bringing (the CoCo with NitrOS-9), doesnt have any of its system routines in ROM beyond initial bringup/boot...

sloopy.

[potatohead]

Doesn't the CoCo 3 have a 32K ROM?

Re:  Switchability.  Honestly, it would be nice to have the ability to just go from Atari to 6809 Atari, but a simple installation that doesn't really modify the machine is attractive enough.  It's not hard to get two Ataris.

Drivewire works on a ROM inserted into the cartridge, doesn't it?  Maybe loaded from disk.

Assuming the 16K ROM works to get the OS loaded, what does the memory map end up looking like?  Many Ataris are 64K machines.  Assuming that's not a large free memory scenario, wouldn't it make sense to use this system to boot-strap a ROM that's smaller, optionally a BASIC of sorts on cart?

[Shawn Jefferson]

Maybe a ROM that implements the basic interrupt code and low-level disk I/O routines, that way you can boot with the 6809, and then load the rest of the NitrOS off of disk (or whatever else).  Full native SIO device support would be nice at some future state too.

Depending on the code size of NitrOS, the Atari way to do this would be one or more of these methods, each with their advantages and drawbacks:

- a banked cartridge (like SpartaDOS X)
- memory under the OS ROM
- extended memory (at $4000-7FFF)

[boisy]

sloopy, on Sun Feb 26, 2012 10:20 AM, said:

Thing is, altho he is running out of room in the OS ROM, this is just for intial debug/development of the hardware, his intention was never to have the full NitrOS-9 in ROM for release... Just like Atari DOS is not in ROM (SDX excluded)...

He can go two ways with this...
1)have minimal bring up and boot capability in the ROM, and the rest in RAM (similar to a modern PC)

2)Have minimal bring up and boot capability with common system routines in ROM, and the rest of the OS in ROM (as Atari OS/DOS is done)

Which way Boisy goes is up to him, but I would guess he would go with the first, as the machineand OS he is coming from and bringing (the CoCo with NitrOS-9), doesnt have any of its system routines in ROM beyond initial bringup/boot...

sloopy.

Sloopy is right.  NitrOS-9 carries all its routines in modules in its boot file and does not depend on any ROM routines.  Also, the OS is running in all RAM mode, so switching to ROM to execute code there would require pre knowledge of locations and switch management.

One thing that is important to remember about NitrOS-9 is that it really, really loves contiguous memory and wants complete reign of that memory.  It also wants the freedom to order itself in anyway it chooses.  That's the basis for its modular design.

When I say "modular" I mean that each important piece of the OS is literally, a module.  A module has three parts:

1. a header which describes its properties (name, size, whether its a program module, driver module or other).
2. the content (program code)
3. a tail (3 byte CRC)

All code in OS-9 runs in "position independent" mode meaning that there are no references to absolute addresses.  So a module can be loaded at $5017, at $733F or at $A913.  All are perfectly valid addresses, and the code inside the module is expected to perform its branches relative to its current position.

Here are the important modules:

- Krn (The kernel)
- KrnP2 (More of the kernel in a separate module)
- IOMan (responsible for defining control and data structures for I/O)
- Init (a "data" module which contains no code but does contain information about the system, referenced by the kernel and other modules)
- SCF (sequential file manager, responsible for management of character oriented devices like terminals, printers, etc)
- VTIO (the video terminal driver which brings video and keyboard services... this is system dependent, obviously)
- Term (a device descriptor... you read and write to device descriptors.  It's an information module without any code, that ties a file manager and device driver together)
- Clock (sets up the timer for multitasking and manages the system time)
- Clock2 (an extension for specific hardware real-time clocks, called by Clock)

[boisy]

potatohead, on Sun Feb 26, 2012 11:47 AM, said:

Doesn't the CoCo 3 have a 32K ROM?

Re:  Switchability.  Honestly, it would be nice to have the ability to just go from Atari to 6809 Atari, but a simple installation that doesn't really modify the machine is attractive enough.  It's not hard to get two Ataris.

Drivewire works on a ROM inserted into the cartridge, doesn't it?  Maybe loaded from disk.

Assuming the 16K ROM works to get the OS loaded, what does the memory map end up looking like?  Many Ataris are 64K machines.  Assuming that's not a large free memory scenario, wouldn't it make sense to use this system to boot-strap a ROM that's smaller, optionally a BASIC of sorts on cart?

Yes, the CoCo 3 has a 32K ROM on its motherboard.  DriveWire can run in the motherboard ROM or it can also be placed in the cartridge.

16K ROM is more than enough to load the OS from DriveWire over the SIO.  The memory map will be all RAM.  The map will look like this

$0000-$04FF: OS globals, data structures and system stack
$0500-$08FF: Screen memory for 40x24 screen, Display List
$0900-....: Memory available for allocation by apps
$8000-$BFFF: used by the OS.  The lower number is variable.  It could be more, or it could be less depending on the boot file.
$D800-$FFEF: used by the OS.  It is expected that the boot file will be at least this big.  Although it may not.  Again, NitrOS-9 is modular and you can have a very minimal system.  Whatever the OS doesn't use for its modules goes to the free RAM pool.

NitrOS-9 allocates memory for modules from the top down, and allocates memory for the application's data from the bottom up.

It's a trade off... a bigger bootfile means less space for apps, but more functionality.  A smaller boot file means more limited functionality but more room for apps.  That said, NitrOS-9 really shines on a system with more RAM, like 512K.  For those systems, there is NitrOS-9 Level 2, which has memory management features, since the 6809 can only address 64K at a time.  

NitrOS-9 Level 1 is for systems with only 64K of RAM, and that's what is being ported to the Atari.

[boisy]

Shawn Jefferson, on Sun Feb 26, 2012 1:50 PM, said:

Maybe a ROM that implements the basic interrupt code and low-level disk I/O routines, that way you can boot with the 6809, and then load the rest of the NitrOS off of disk (or whatever else).  Full native SIO device support would be nice at some future state too.

That's what the current boot rom that I wrote does.  It has an SIO read and an SIO write routine, along with basic code to set up the hardware to a sane state.  Then it requests 32K from the DriveWire server, loading that from $8000-$FFFF, then does a jump to the address stored in $FFFE-$FFFF (which in the 32K of loaded code points into the entry point of the NitrOS-9 kernel).

Shawn Jefferson, on Sun Feb 26, 2012 1:50 PM, said:

Depending on the code size of NitrOS, the Atari way to do this would be one or more of these methods, each with their advantages and drawbacks:

- a banked cartridge (like SpartaDOS X)
- memory under the OS ROM
- extended memory (at $4000-7FFF)

Read the message I posted earlier.  The OS can be as large or as small as you like, and is totally configurable.  Having a simple ROM on the motherboard that just loads the OS, then gets out of the way is really the best way.

That said, I want to mention that NitrOS-9 is but ONE way to use the 6809 in an Atari.  Another way is to write one's own OS or environment.  That environment could very easily check the cartridge and do things completely different from NitrOS-9.

I just happen to be partial to NitrOS-9 so that's what I'm focusing on.

[sloopy]

boisy, on Mon Feb 27, 2012 6:43 AM, said:

Shawn Jefferson, on Sun Feb 26, 2012 1:50 PM, said:

Maybe a ROM that implements the basic interrupt code and low-level disk I/O routines, that way you can boot with the 6809, and then load the rest of the NitrOS off of disk (or whatever else).  Full native SIO device support would be nice at some future state too.

That's what the current boot rom that I wrote does.  It has an SIO read and an SIO write routine, along with basic code to set up the hardware to a sane state.  Then it requests 32K from the DriveWire server, loading that from $8000-$FFFF, then does a jump to the address stored in $FFFE-$FFFF (which in the 32K of loaded code points into the entry point of the NitrOS-9 kernel).

Shawn Jefferson, on Sun Feb 26, 2012 1:50 PM, said:

Depending on the code size of NitrOS, the Atari way to do this would be one or more of these methods, each with their advantages and drawbacks:

- a banked cartridge (like SpartaDOS X)
- memory under the OS ROM
- extended memory (at $4000-7FFF)

Read the message I posted earlier.  The OS can be as large or as small as you like, and is totally configurable.  Having a simple ROM on the motherboard that just loads the OS, then gets out of the way is really the best way.

That said, I want to mention that NitrOS-9 is but ONE way to use the 6809 in an Atari.  Another way is to write one's own OS or environment.  That environment could very easily check the cartridge and do things completely different from NitrOS-9.

I just happen to be partial to NitrOS-9 so that's what I'm focusing on.

Well the ground work for a common 'platform' needs to be done, this is what your getting done.

Also for more ram the standard method is 'paging' 16k blocks in at $4000, using the PortB bits for up to 1Meg of extra RAM, 256k and 512k are common tho... This is confused by the fact that, 'back in the day' XL mem upgrades would use 64k of that 256k or 512k for base 64k, and the rest would be 192k or 448k of 'ext mem', and in XE's have seperate base and ext mem, so on them the full 256k or 512k would be ext mem... But in recent times ram upgrades have given full ram to ext mem...

sloopy.

[boisy]

boisy, on Mon Feb 27, 2012 6:40 AM, said:

$8000-$BFFF: used by the OS.  The lower number is variable.  It could be more, or it could be less depending on the boot file.

That should read $8000-$CFFF.