The '816 has a 16bit stack pointer; so the stack can be thousands of bytes.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

So than putting it at the very end of all the addressing isn't a bad idea. I'm going to work it out and see how I can get the RAM at the very end of addressing, and see if that simplifies the rest of it

If you're staying in '816 mode, you can also move the Direct Page anywhere, which means that Page 0 and Page 1 are no longer special, like they are in the 6502. They're just memory like any other.

I remember reading that in the docs, and I do intend on staying in 816 mode, so I'll probably end up moving both of them (I may keep zero page at 0 though, since I have ram there) is zero page 16 bits as well? if so it may be a good idea to move it to the start of the 4M module if it's installed, to have a 64k zero page

Direct page and the stack must always remain in bank 0. Although the stack can be huge, the direct page is always 256 bytes, but can start anywhere in bank 0, and doens't have to start on a bank boundary, although you do save a cycle with every DP access if it does start on a bank boundary. In multitasking, each task can have its own direct page and its own stack space.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Like the stack, Direct Page has to live in Bank 0.

But it can be anywhere in bank 0 (it doesn't even have to be page aligned).

Ok so then it is going to have to live in my first 32k of ram then correct? I guess that's a bit of a bummer, but I doubt I'd ever need 64k stack. I suppose I can still have 32k-256 stack, and leave the zp where it's at, but I still doubt I'd ever need even 32k-256 stack.

At any rate, I just finished wiring up the 4M memory module, using a 3 to 8 on A21-A24 to select each chip select, so it should be living in the top 4M of address space now.

Ok so since I'm getting more comfortable with getting this schematic laid out I've started thinking about peripherals. I think, from easiest to hardest, this should be, Keyboard (PS/2 or DIN-5), Sound (VS1000 looks good for this, reads ogg files and outputs at headphone level), and Video (Still looking at the VS23S010D, working on understanding all the information in the data sheet).

So I have a few questions here.

A: can I use channel B on the DUART for the keyboard connection, it seems like the keyboard needs a clock line as well, but I'm wondering if I could use one of the timer outputs of the DUART. (only issue is the CPU would have to handle all interrupts generated by the keyboard, but hopefully that isn't that bad)

B: I've been debating on sound generation vs sound playback. The VS1000 seems to make it easy, I can load ogg files to its internal NAND flash over SPI, and tell it to play them at certain times (not sure if it supports playing multiple at once). But I do like the idea of being able to generate custom sounds as well. Also, since the VS1000 is addressable over SPI, I could put it on a daughter card and worry about building it and setting it up until later.

C: As far as video goes, that schematic I linked earlier in the thread is helping out quite a bit, but I'm stuck on another part here. I'm debating between interfacing it over parallel, on the processor busses, SPI, behind the 65SPI, or parallel behind a 6522. I'm pretty sure interfacing parallel over the 6522 would be no net gain over interfacing over SPI behind the 65SPI, so I think I'll leave the VIAs to do something else. I am wondering if I can get a net speed gain by interfacing parallel over the processor bus though, since I can clock whole bytes in at once. The issue here is, I've been thinking about attaching a small text display for initial setup and debug of the machine (I know, earlier I claimed I didn't want to do this because I can't get much text on it, but just for setting the machine up and getting the NTSC video running, it could help). This means I could potentially hold off on the video, putting it on a daughter card. If I put it on a daughter card, I'd prefer to run it on SPI, so I'm not running processor busses off the board. This could allow me to, like with the audio, not worry about building and setting it up at the beginning (and if I have both on daughter cards, the board has no SMD soldering required, because the only SMD chips are the audio and the video.).

And, as a final question, (this may be in the interrupt primer, I've been reading through it again but haven't finished it), how does the CPU determine which device pulled IRQ low? Does the device pulling it try and assert the data bus? Or do I need to build a mechanism to tell the CPU which device did it?

Typically, the Interrupt Service Routine will check each of the devices it knows about, in some preferred order, to see which one caused the interrupt. I dare say it's possible to set up some kind of register that the 6502 could read, and technically possible to twiddle the interrupt vector as it's read, but neither is normally done in 6502 land. Bear in mind that two interrupts could occur and both need servicing by the time the ISR is entered.

I just found the part of the primer that talks about this, and polling all of the interrupt sources you may have.

I'm wondering if you could get a speed gain by doing something like an external register with device IRQ lines mapped to each bit. Since polling a lot of devices may be costly.

It's really a question of scale. It's only costly if you have
- many peripherals
- relative to CPU speed
- and tight deadlines

In other words, I think it would make sense to use some numbers. See how many instructions, therefore how many nanoseconds, get used, compared to how many you need to get things done. My guess is that all is well and you'd be prematurely optimising to worry about this. Unless you're building a massive terminal concentrator with high data rates.

It is probably worthwhile to check the most time-critical device first. If you're doing audio work based on timed interrupts, that would be important. Unless you have FIFOs to smooth things out.

Acorn used IRQs for rather a few devices: two VIAs, the UART, external devices on the expansion bus. The VIAs themselves combine IRQ sources such as the timers, the keyboard, the light pen, the video sync, the ADC conversions, the sound chip. Whereas floppy disk and network events got an NMI to service them: rather more time-critical. I'm not sure how those two NMI sources interoperated, if indeed they did.

Honestly, your first device should be a UART talking to a terminal booting in to a monitor that you can use to load in programs and run them.

It's simple to do, and the advantages far outweigh the costs up front.

You can always remove it later.

Then you can use this capability to get your keyboard bootstrapped, as well as your other devices.

When you have your keyboard show characters on your video screen, you now boot in to that to work from that instead of the terminal. You can still use the terminal to echo out debug info if you like, and for off board file transfers.

Eventually, you get to be completely standalone and can stop using it entirely.

But bang/buck a UART up front can't be beat.

I do have a UART on board (the 28L92 DUART) and it's wired up to a MAX238 that's then wired to a DSUB-25 connector for RS-232. (it seems to handle 2 RS-232 connections, but I'm not presently using the second one, so I could unwire it and use the second channel of the DUART for something else) Here's a picture:



EDIT: forgot to finish this post.

I suppose I could just hook it up to a serial terminal, but I'd like to have it figured out now, before making the PCB (since it's growing increasingly clear that I may have to have the PCB made rather than using my CNC). As you say, I can forgo ordering the parts for the perihperals, but at least the board will support them

Also, in addition to my last post, I mean to ask, should I use the DSUB-9 connector for RS-232 instead of the DSUB-25? Wikipedia lists DSUB-25 as the standard, but I think a lot of cables and devices still use DSUB-9

You may want to consider a header for a TTL output to use with a usb <-> TTL serial adapter as these are considerably cheaper than true rs232 usb serial adapters.

That's essentially all I use - and my whole board is powered via the USB 5v supply too.

(and I'd go 9-pin just for size - also no PC made in the past decade has a 25-way serial port)

(or any serial port for that matter)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/