Memory map

[banedon]

Hi guys

I've recently returned to my 65C02 cross emulator (6502CA) which I've been writing for what feels like forever .
Much of it is done functionality wise, but with a few exceptions. Once of which is the implementation of a basic memory map facility usable by the Simulator part of the project.
The basic RAM/ROM side of things will be easy to implement, but I was wondering about basic VIA/ACIA implemetation and whether it's worth adding this in or just have a generic "I/O" classification.
If do try going beyond simple "I/O" then should I just have registers - at which ppint might as well be RAM - or should I try adding in (for the VIA) timers and maybe basic IRQ vector calling and have the port A and B have a window which you can toggle the lines on? Is it worth the effort?
Timers might be not worth it as the Simulator is not an Emulator and so, although it keeps track fo cycles, does not adhere to any time specifications and takes as long as it takes to execute a given instruction.

[Chromatix]

You could tie an ACIA emulation to console input and output, which would make your emulator much more useful than a pure RAM/ROM model. That's probably the first thing I'd do.

The next most useful thing would be the VIA's timers, which you can use to give your emulated machine a sense of time independent of its instruction execution rate. Feed your virtual VIA with a 1MHz clock on one timer and a 32kHz clock on the other, or something similar. Or skip the VIA (it's actually quite tricky to emulate *correctly*) and implement some simple RTC chip.

[BigEd]

Yep, I'd certainly go for the ACIA next - really just a byte to read and a byte to write, no need to model control register and you can probably even get away without modelling the status register.

After that, a byte-wide In port and a byte-wide Out port might be good, if your emulation is suited to emulating a bank of LEDs and a bank of switches. That's the very basics of a PIA.

And then, yes, modelling some kind of timer might be good. Perhaps not trying to match the VIA behaviour precisely, but something good enough to set up a heartbeat interrupt.

[banedon]

In that case I'll give it a go. Down side is that I'll need to write in an abstraction layer for ram access for intercepting read/writes not destined for RAM, but as speed isn't a huge issue it should be ok.

EDIT: Also will have to add in an an IRQ system, Timers, line interface. Should be fun!

[whartung]

Depends on your goals.

For mine, I simply have "magic" addresses. For example, I have an address that returns 0 or 1 if a key is ready, and another that returns the key value. Similarly, if I write to an address, a character appears on the display.

I also have a set of contrived disk operations to read and write blocks from the "disk".

These don't mimic any known hardware. But they're perfectly adequate so far for writing 6502 software.

So, if you just want character I/O, do character I/O. if you want to mimic hardware, throw interrupts, and such -- then do that.

Mind, my system just interprets instructions, it doesn't do cycle by cycle processing, doesn't mimic lines from the chip to the pins to the bus, or anything like that. It's simply a 6502 interpreter. When you start mimicking hardware, that may or may not be enough, depends on how far you want to go.

[banedon]

Not got that (yet) for input, but I do have something similar output-wise. I have simulator options which cause JSRs to specified addresses to be intercepted and display things in the assembler output window. Here's a screen shot. Got to admit the descriptive text needs a bit of work (as does the layout - all being rearranged atm), but I hope you get the gist. These special modes can be enabled by command in the source code as well as in the GUI:
Syntax:
SimOptText <mode> <status> <intercept address>
E.g.
SimOptText 4 Enable $FFEE

With regards the I/O mapping:

I think having this would be handy for trying basic I/O stuff so am proceeding with VIAs and will then look at ACIAs.

So far I've built some structures for up to 4 VIAs, adding in an abstraction layer for RAM read and writes so I can intercept stuff forIO, ROM, etc and have implemented partial access to VIA registers.
No GUI, timer, etc. stuff for VIA interaction and still got to do the IRQ stuff. Getting there.

[unclouded]

Chromatix wrote:

You could tie an ACIA emulation to console input and output, which would make your emulator much more useful than a pure RAM/ROM model. That's probably the first thing I'd do.

I did this for my CoffeeScript-based emulator. From the command-line I can now invoke the emulator, passing a .prg file and it starts up and interacts via the console. I had to implement support for IRQs because the ACIA code in my monitor uses them.

Although the emulator only emulates at the instruction rather than cycle level, I found it much easier to emulate the memory map "properly" with an emulated address decoder and an API that a bus device implements because it simplified the decision-making process. Having to make decisions slows me down.

[CurtisP]

whartung wrote:

For mine, I simply have "magic" addresses. For example, I have an address that returns 0 or 1 if a key is ready, and another that returns the key value. Similarly, if I write to an address, a character appears on the display.

I would have it return 0 or 255, that way it can be tested with the BIT instruction.

[CurtisP]

I like the idea of emulating VIAs, since nearly every physiical 6502 based system used some variation of them.

[BigDumbDinosaur]

banedon wrote:

I've recently returned to my 65C02 cross emulator (6502CA) which I've been writing for what feels like forever .

A pedantic note: what you are creating is a simulator, not an emulator. Emulation implies the use of a specific type of hardware that is capable of being made to faithfully act like the actual 65C02.

[GARTHWILSON]

BigDumbDinosaur wrote:

banedon wrote:

I've recently returned to my 65C02 cross emulator (6502CA) which I've been writing for what feels like forever .

A pedantic note: what you are creating is a simulator, not an emulator. Emulation implies the use of a specific type of hardware that is capable of being made to faithfully act like the actual 65C02.

Our discussion on that is in the topic "Terminology: Simulator vs. Emulator." (I agree with BDD.)

[BigEd]

And there the discussion should stay, ideally. "Pedantic" is a confession, as much as a description.

[BigDumbDinosaur]

BigEd wrote:

And there the discussion should stay, ideally. "Pedantic" is a confession, as much as a description.