6502.org

MoGameSS
MOdern GAME System Specification

so the working title is bad and ill change it in a bit,
based on interaction on this forum, research, market trends and a recent 6 hour focus group with modern NES developers in the EU, Australia and Asia, the 'Specification' taking hold. The model device is a portable system with a color lcd screen and has expansion ports. It has an adapter or docking station to play games on tv.

We will be using the 8-bit ISA bus on this system. it will run faster than the cpu most likely.
It will have a 65c02, @8-12 mhz (maybe faster or overclockable by users, it is a multiple of the system bus)
and probably one or more 6522.
It will have a PPU/LCD driver acting as a gpu with tile mapping, bit blit engines, line and box drawing with a large ram space.
The PPU will most likely be running 3-8 times faster than the cpu
Primary video is 480x272, which upscales to 1080p, (480*4 = 1920, 272*4=1088) with minimal loss.
There will be an audio circuit that can produce stereo out, with a square, sine, tri and noise generator on each channel, controllable by envelopes, FM wavetable or 8-bit PCM module.

• The system mimics a 6809/6509 type system with 1MiB of address space, per the ISA standard.
• A controller called the ISACoder or ISAC/ISAAC chip, will provide the addition 4 bits of addressing for 16 64k banks, viewtopic.php?f=4&t=7577
• DMA will allow devices mapped to these banks to talk to each other.
• IRQ from ISA will be decoded to the NMI/IRQB signals of the 6502 (or 6522 control lines to further be decoded)
• IRQ upper lines will allow banks to call each other with IRQs, not just the 'cpu'
• primary cpu resides in bank 0, with all vectors at 0fff0-0ffff, this means in this bank, the 6502 operates as normal and can swap banks via a command to the ISACoder.
• It is likely that at least one bank be 'scratchpad ram' of 64k
• one bank will be reserved for peripherals, and once swapped to this bank, the system can 'boot' to this bank like ROM cartridge if desired,

it is open hardware.
The system is much less expensive than modern gaming console and on par with a used laptop or tablet.
The system can be modified based on region or availability of components as long as vendor provides drivers or cross compilation libraries

There will be a basic monitor, bios, os and/or software suite.
Developers will have a strong, reliable platform for development for many years.
Other vendors may support this specification.

Current options for the GPU
4D EVE, Epson S1Dxx, RAio 8875

Address Space Map

due to the 6502 having 16b innate addressing, for ~64k byte of space, and our goals to have the full
1MiB of 8-bit ISA address space it is logical to utilize 16x 64k "Banks" of Extended Address Space.

Because we are using an external ISA and DMA Controller, and we do not want to utilize a lot of
'timing tricks' to try to emulate full 20b Address Space, or work like the 65816, it further stands to
utilize Bank Switching as our method of extension.

Our Current Address Space Map is

Bank # Allocation
0 Native 6502 Addressing (the 6502 normal space, in this everything is normal)
1 --------------------------
2 --------------------------
3 --------------------------
4 --------------------------
5 ---64k Scratch RAM----
6 ---------GPU/ RAM------ (based on 384k of ram on the ppu/gpu, may be internal)
7 -------------""-----------
8 -------------""-----------
9 -------------""-----------
A -------------""-----------
B -------------""-----------
C -------Controllers------- (for additional devices connected to the system through its onboard ports)
D --------------------------
E -----Expansion Slot----- (this is the 'cartridge' slot where External ROMs go, hot reset vector to boot from here)
F ------Function ROM----- (this is 64k of programs and routines used by the system as needed)

There are several areas unused, and we may not use the entire range, however Banking allows a lot more space to be used.
All of the GPU/lcd driver chips we are looking at use vast amounts of RAM compared to the native 64k of the 6502.
Some chips use internal and some use external ram, and this will further change the 'specification' as we go.
Again, this is tentative and we are establishing a Specification for any vendor (this means you) to build a device to conform to.
Our goal is 'good games, good times, good code', and we are trying to make it easier for people to develop games,
for 8bit systems, in 2025 and beyond.

So we are planning to make one of these, and this will be listed on an open hardware repository at some point.
For now, establishing 'what works' is the next step. Id like an Audio Bank, though its important to remember,
most devices will be sent signals to and from the 6502/6522 directly, in the Bank 0, Native Address Space.

6502 Native Address Space

16x 4k Nodes
0 RAM
1 RAM
2 RAM
3 RAM
4 RAM
5 RAM
6 RAM
7 RAM
8
9
A Audio Chip?
B
C Controllers, 6522 VIA
D
E ROM
F ROM --FFFA-FFFF vectors

Same question as before: if this is to be via bank switching, so that one and only one of these 64KB banks will be visible to the 6502 while executing code ... the 6502 needs to see ROM or some sort of persistent memory with the IRQ/BRK, NMI and RESET vectors in the logical address $FFFA-$FFFF, it needs to see RAM somewhere in $0100-$01FF wherever the stack index is taking stack operations, it needs to have RAM to work with somewhere in the logical $0000-$FFFF space when executing code, it needs to have the code it is executing somewhere in $0000-$FFFF.

The FFFA-FFFF vectors in bank F do no good if a BRK occurs when executing code in the ROM in the E bank, or executing code in the RAM in the 1 Bank.

The RAM in Banks 0 up to perhaps 7 do no good for executing a subroutine call in the ROMs in Bank E or F: the ROM, being Read Only Memory, cannot store the return address for the JSR instruction.

Translating the above physical address space from $000000-$0FFFFF into a logical address space from $0000-$FFFF results in a lack of a complete functional set of resources for the CPU to do it's work, no matter which Bank is used, even though there is an abundance of resources spread across the physical address space.

The problem is that any given Bank is the entire 64KB address space that the 6502 can see and use when it is selected as the current Bank.

One of many workable ways to organize the logical address space to access that physical address space would be to have banks on 16KB boundaries, have physical $000000-$003FFF always mapped to $0000-$3FFFF, physical $0FC000-$0FFFFF always mapped to $C000-$FFFF, and then two 16KB banks appearing in the logical addresses $4000-$7FFF and $8000-$BFFF.

$0000 in the logical address space could be dedicated to a register for the bank to go into $4000-$7FFF and $0001 in the logical address space could be dedicated to a register for the bank to go into $8000-$BFFF.

The ISAC will handle a lot of this, and may be able to shadow or mirror different address ranges during runtime.
so no matter what bank you are in, you can 'shadow back' to bank 0 and use the stack there.
Something you and several other people have commented on is this particular topic. This is the system address space and the cpu isnt the only device on the system bus. with bank f being all rom, it makes sense to copy routines from it. The video ram may not be accessible by the cpu without going through its registers. Devices will use DMA to talk to each other, so they might never involve the 6502 at any given point, other than to be issued commands, like Run and Stop, or Next Track. Consider an ISA slot in a desktop version of this. It might get an entire bank dedicated to it, such as Ram Expander, or only a few bytes are used, in the case of an MP3 player add on card, with a 128gb of storage. The 6502 cant see 128gb, it can tell your device to advance to the next song, and that MP3 player can still talk to DMA, the gpu for visualizers and the audio mixer to send the data onward to the speakers.

So System Address Space is 'theoretically accessible' by the cpu anywhere, that doesnt mean people can be careless programmers.
Careful development of a DMA controller and system software should help here.
Im not shuffling 'windows of 16k around'. Numerous people have lamented the thought.

The system space is 1MiB, and the programmer might want to use that space carefully, to avoid problems like you have pointed out, however, with careful use of the system and commands, they should be able to utilize much of it.

What chip will be the PPU that provides all that functionality?

If on power-up, the ISAC "knows" to make the to however many byte of the F ROM page available at the top of the 6502 logical address space, and know to make however many bytes of the 0 RAM page available to the 6502 logical address space ...

... then in what sense is the physical address space split up into 16 64KB banks?

I am giving the reaction of several other people because what was said was 16, 64KB banks.

If the physical address space is not appearing in the logical 64KB address space as a single 64KB bank (which, logically, occupies the entire address space) ... isn't it a bit confusing to say that it is?
So in what sense is that 1MB physical space organized into 16 distinct 64K Banks -- where as we know, in the context of 16bit address space from the 1980s, "Bank" means the contiguous segment of physical memory that appears to the CPU at some span of logical addresses.

Are you perhaps inventing a new meaning for "Bank" from the one that has been used in the 8bit CPU context for 4 decades or more, and so confusing people as to what you are saying?

If what you mean is that the manager of the physical memory manages it as 64KB segments and then flexible sub-segments within that, wouldn't it make more sense to call them 64KB Segments, which doesn't carry the implication that they appear in the 64KB address space all at once?
That is a dramatically different description of what is going on than saying that the 1MB of physical address space is broken on 64KB boundaries and the CPU can only see one 64KB portion at a time.
16KB windows were just a system that was nearly as simple as a single Bank of 64KB making up the entire 6502 address space, yet would also be functional, unlike the suggestion that each 64KB segment of physical memory actually be treated as a single 64KB Bank.

If people don't want to be locked into 16KB windows, simple to work with but more flexible banking systems can be readily specified ... the venerable Z180 Common 0, Banked RAM, Common 1 system over a 1MB physical space mapped into the 64KB address space on 4KB boundaries could be expanded into four zones: Common 0 at $00000 to the start of Bank1, Bank1 from the start of Bank1 to the start of Bank2, Bank2 from the start of Bank2 to the start of Common1, and Common1 at the physical address space from $F0000+Common1_begin to $FFFFF. That is a byte and a half to specify logical windows on 4KB boundaries, three bytes to specify logical windows on binary page boundaries.

Then with a 1MB physical address space you can specific the physical base of each bank with a one byte index on a 4KB boundary, or with a separate segment nybble and sub-segment byte, on a 256byte page boundary. So you can easily specify symmetric sized RAM and ROM banks to copy from ROM to RAM, but you can also specify a 256 byte I/O register space that can placed as high or low in the address as is convenient.
I was just pointing out that in the terms that were used to describe the project, the design was unworkable, but as you describe how it is intended to operate, it seems rather that you mean that the 1MB physical address space is organized into 64KB segments, rather than it being organized into 64KB Banks. 64KB Banks are clearly unworkable. Given that an 8bit processor is talking to the registers of the memory map manager, a system of 16 segments, which implies a 4bit segment index, and up to 256 subsegments within each segment, on binary page boundaries -- which implies an 8bit sub-segment index -- could be quite convenient.

it's important that the core registers of the memory map manager are somewhere in the Common0 area that includes the zero page and stack page, which is why it is not unusual for them to be located starting at $0000 in the logical address space, and to be concise enough that not too much zero page space is given over to them. Extended functions could be brought into the logical space as additional I/O registers in a banked window (of whatever size), but the core registers to bring that into view need to always be visible.

So one approach which would fit the design of the 6502 would be to dedicate the first page of the I/O segment to $0200-$02FF, and if that includes the registers of the memory bank manager, that would then include the capability of bringing in whatever additional I/O register space by banking them in from the I/O segment.

Current options for the GPU
4D EVE, Epson S1Dxx, RAio 8875

The 4d systems is based on their own chips, or a various others, the Picasso and goldelox chips are based iirc on the Bridgetek FT81xx.
Is not our top pick at the moment, though we explored it for other designs.

RAio has the 887x, with the '73 and '75 offering a lot of potential. These are very similar to the Epson S1D chips. This is a top choice at the moment, because of overall compatibility with our designs. it offer 8x8, 16x16 tiles with 'bitblit', it has line drawing and user defined tiles along with a few other whistles and bells. There is a cheap lcd module with an 8875 on a 480x272 screen for like, $45 usd, so for a gpu and monitor with support hardware thats not bad.
https://www.raio.com.tw/en/RA8875.html

the Epson S1D series has a lot to offer and they have a broad selection of chips, many of which have features that may be unused. It is likely that some of the other chips on the market are based off of these designs:
https://global.epson.com/products_and_d ... ntrollers/

not 100% sure yet, there are still a lot of decisions to make, Ill know more as things are prototyped and we get closer to some kind of 'launch'. it may or may not be shared vram, it might be a different provider. If a vendor (you or company x) want to use a different chip, its fine, as long as it meets the specification or provides a driver or library to compile to, you can make some substitutions.

Some really great chips out there that offer a lot of value to the 6502, and a Modern Gaming System, based on current technology, can extend this architecture a bit longer and offer some Amazing Games to play!

no we are not doing things that way here. Thanks though.

the ISA specification uses 4k minimum sized Nodes.
https://bitsavers.org/pdf/intel/_busSpe ... _Sep89.pdf

ISAC does a lot of work on this system.

Cheers!

That's a terribly blunt way to respond to a long and thoughtful contribution.

(I'm not here, by the way - I find your threads problematic.)

you are welcome to ignore or block me,

I did not find Bruce's posts to be a helpful contribution,
I felt it important to be clear and upfront that i was following an existing schema and that they are 'barking up the wrong tree'.
I was quite polite and tried to let them know it was not anything against them, i just have already decided to go a different way.

what rude is you piping in here to attack me en masse like you just did.
BigEd, please dont speak to me in the future, I dont like being antagonized like you just did.

see how easy it is for a person to speak up for themselves without someone running in to start a fight?

BruceRMcF, I guessing you mean well, its just not a problem I need to solve, using a window is inside out.
I dont want to go back and forth justifying and explaining all of my reasons, the concerns you have, are things I have workarounds for, the same solutions other people use for these problems. Its a different way of thinking about it. To me, every address is access to terrabytes, one byte at a time. Hopefully, as the project grows you will see how we do things.

the ISAC thread has some new material Im adding later.

Hey wayfarer,

Just curious about this project. You say, "we" and "our"... Sounds like it's a serious effort! If you don't mind answering, how big is the current team, and what kinds of disciplines do they have?

Cheers and good luck!

on this one, mostly me right now, its just a Specification though to come back to later.
for my other project, Tinker viewtopic.php?f=4&t=7589
on that project there is :

• myself, 3 professors at my university,
• my professor, an ieee committee member,
• my other professor, who did tech research for 20 years before teaching, that runs the senior design teams,
• a senior design team of 20+ college students in the computer engineering department to test it,
• and a professor that does compiler design from comp sci to help out on the programming side.

I do a lot of interviews with other educators and professionals.

this project is really just a draft Im working on, for a system i will build after Tinker is done. its more a specification others can build to ISAC can probably be replaced with an mcu running custom code, you could put an '816 in yours if you want. Its an open standard and if I can get it going, I think it would do well to unify many hobbyists to better exchange software and games.

Gotcha.
That's pretty neat. Looks like it's been a work-in-progress for two years now. How's it going? Do you have a completed schematics, PCBs, and software? Oh... I guess it would be better to post an update in that thread rather than here.
It's sounds like you're fairly settled on a number of system design areas. Is it your intent, then, that your university colleagues will help you realize this, physically? That sounds like a great collaborative project for an undergraduate team.

What made you title this thread as a "Modern" Gaming Specification, when you're selecting 70s/80s era CPUs and ISA bus? Did you think "Classic" or "Retro" were over-used labels? Or are you thinking modern as in using modern FPGA/CPLD solutions?

no not for this, and it is not something I think I would ask them to, they are on an different educational project with me, as you said, for undergrad research and curriculum.

no, its just a "ultra newtendo" for the 2025 technology, 50 year 6502 anniversary era.
this, this is because I love the 6502 and I love games. its a completely fun and entertainment oriented project. As stated, I ran a 6 hour focus group from current NES developers, and because part of this is, making your own, its like a guide to follow and gives developers a common platform to share games. As long as there is driver or compiler libraries, many of the components can be changed and reconfigured. Mostly, its a bunch of modernized 'standards' that are adhered to, and some kind of address schema.
I have 6-10 65xx based projects Im working on, including a custom core at some point down the road.