Mike (banedon),

Congrats' on bringing up the prototype with extra RAM memory. This is potentially "way cool".

May I ask how you might use the extra memory, please? My only experience using expanded memory was on the Apple II which overlayed 16K RAM banks into the ROM address space ($D000-$FFFF). This provided a way to switch out Applesoft in ROM for a 16K RAM bank which contained Integer BASIC. Apple also ported a version of UCSD Pascal that took advantage of the nearly 64K RAM memory map.

While working for Legend Industries I wrote a program called Memory Master for their 64K and 128K RAM cards that would load the missing language, Integer or Applesoft, into one 16K bank of RAM with the option of relocating Apple DOS 3.3 into another 16K bank. Relocating DOS would free up 8K in the lower 48K RAM address space available for BASIC by reducing the DOS 3.3 footprint in that area from $9600-$BFFF (10.5K) to $B600-$BFFF (2.5K). The portion of DOS remaining in the 48K space at $B600-$BFFF contained the DOS I/O hooks, memory manager code, and DOS buffers.

Since I'd like to be able to run something like Apple UCSD Pascal and other languages on my next 65C02 system, I think the ability to map RAM into the ROM address space is important.

Good luck on your project.

Cheerful regards, Mike

Hi Mike

I'm not sure if you're asking what the RAM is going to be used for or how it's being swapped...? With regard to what I'm going to use it for then:
I've always wanted to try mapping RAM, although I have no super pressing need for the moment. My design is based on a small amount of fixed (non-banked) RAM to be used for zero page, the stack, and the rest (up to $FFF) for use by user programs and to run any user-based RAM bank swap code .
Speaking of Apple, this the way I do this was suggested by Peter (cbscpe on the forum). He recommended it as this is something that Apple used. The BBC Micro also used latches for I/O control, although not memory mapped, but through its VIAs.

If you're after an explanation of how the latch system works then please let me know; I'll be happy to advise. Sorry if I've misunderstood what you're asking.

(I think the bank switching on the beeb is done with a memory mapped latch, although the two vias are used for other I/o purposes.)

Hold on: Time to get the Advanced manual out

[edit] I was thinking the Addressable Latch which is operated from port B lines 0-3 of the System VIA. Are you thinking of "Jim" at &FCxx which controls (amongst other things) the "extra" 64KB of RAM which can be paged in/out?

[edit] typo fix

OK, I was thinking of the write only ROM select latch at address &FE30 - that's IC76, a 74LS163 according to
http://mdfs.net/Info/Comp/BBC/Circuits/BBC/bbc.gif

Edit: you've picked up on IC32 which is indeed hanging off port B and is used to access the speech ROM/serial ROM I think. And the "ashtray" ROM socket. And the 76489 sound generator? And the keyboard!

Ahh right. I was just looking at that. That' a 4 bit counter according to google, but given the way it's being used it might as well be a latch.

Yep that's the one.

You're right - slightly odd, but it is a serviceable latch!

Job done. The VIAs are hooked up. I think I'll leave the ACIA for the moment.

How do you guys normally go about doing speed tests? I can see activity (using my 'scope) on the address/data buses when I run the board at 25MHz, but am not sure how else to check.

Correct.

If the rise time on /IRQ is too long relative to the Ø2 clock rate the MPU may still see /IRQ as being low after the most recent interrupt has been serviced and control has been returned to the foreground process. The result will be a spurious interrupt, as the new "interrupt" was not caused by a device in the system, but instead was the result of the time-constant produced by the pull-up resistor's resistance and the circuit's parasitic capacitance. Garth and I both discuss this phenomenon in our interrupt articles.


Generally speaking, yes, as long as the weakest device on the /IRQ line can tolerate the current. Also:

• Clear all interrupt sources in your ISR as early as possible. This gives /IRQ more time to rise back to Vcc.
  
  
• Arrange your unit's layout to keep the length of /IRQ traces (or wires) as short as possible.
  
  
• SIP-type resistor arrays tend to have a little less inductance than discrete leaded components, so use a SIP if possible.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Caution it's not the ADDRESS command, ADDRESS is the name of the field! and you give the range in square brackets. So it's your definition of the field




and then you use the name of the field and specify the range of values

Argh. The latch is playing up. It seems to be not setting correctly at anything but single cycle step speed.
I've tried qualifying the enable with PHI2 being high, but that hasn't resolved the issue. I'll have to look at it tomorrow and see what the timing is doing. Annoying.

Does it simulate in WinSIM?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Works fine in simulation, so I think it might be timing as the issue seems to be based off of speed. I've been manually cycle stepping it while testing so didn't notice the issue. As soon as the speed picks up it starts missing things out. I'll try padding the LDA's used to set the latch with NOPs tonight to see if it's a case of the latch not having enough time to recover from the previous access.

Padding doesn't help. The only thing that does is single stepping it. I'll keep at it.

[edit] seems to be a decoding issue in the 2nd GAL... it's currently got an input of Read Bank 00 and Writebank 00, but outputting A16 high & A15 low when it should be low for each. If I simulate it then it works. If I breadboard it with an address of $1000 and Read/Write bank bits of 00 for each then I get A16 high and A15 low.

Looks like you were right, Peter: I think I need to redo the decoding without using the TABLE.

[edit] nope. It's incorrect levels on Q0-3 (outputs) from the latch for SBR0/1 and SBW0/1 signals. It seems to be (every so often) be assigning a value to a bit not being addresses. I've buzzed the S0 to S2 lines out with A1 to A3 and D with A0. All ok. They are also not shorted to their neighbours. The latch IC is also ok if tested on a bread board with me setting up S0-2 and D, then setting G low, then back HI.
I think maybe the device is being left selected too long, or is being selected too quickly - so picking up the wrong info on the address bus. I'll try qualifying the latch selection in GAL1 with PHI2.