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

Yes indeed, this matches my understanding of what happens.

I see my confusion now: I'd misunderstood what you wrote. You said:


For some inexplicable reason, I thought you were describing an aspect of the proposed hardware, whereas I now see you were noting a constraint which falls on the software. That's fine! (And it has been done, in the past, at least in HP's multi-ROM calculators which cross-jump in a most spaghetti fashion but always with correct code at the destination, AIUI.)

Garth: we have several threads explaining the '816. Perhaps we just need a sticky post which pulls them together. Not everyone who chooses to design an interesting and ambitious 6502 project is unaware of the 816: it would suffice to mention, in one line, the sticky thread, just in case they need guidance. This particular thread struck me as a case of someone going in an interesting direction for reasons of exercising ingenuity, not out of ignorance of the '816.

I think it's worth mentioning André Fachat's CS/A65 CPU board containing a 74LS610 based MMU.

(From memory and it's been a few months since I looked at this for many reasons, so I may not be quite correct here, but...)

It's a 65c134.

At least the way the 134SXB is setup that is achievable with the on-board stuff in the '134 itself. the SXB has an on-board 128KB Flash ROM pagable in the $8000-$FFFF region as 4 banks of 32KB.

So in another system a simple 2-bit latch is all you need and to switch, you call code in the bottom 32KB to do the switch then return to the upper bank of code.

My thoughts (and initial tests) with the SXB board I have has involved programming the upper part of each of the 32KB bank identically, so code running in that section can switch to another bank by using the output latch bits and carry on working. This is arguably wasteful of the space, but it works for me and goes back to my BBC Micro days (16KB at the top, then 16KB switchable then 32KB RAM)

The '134 has a few 8-bit ports built in but sticking a VIA on a 6502 would achieve the same thing, and again, from personal choice I'd essentially copy the BBC Micro. That had up to 16 banks of "sideways ROM" but there were expansion board to take it to many more (and RAM).

Just an idea...

-Gordon

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

Tricky, but shouldn't be risky - It was solved in the BBC Micro in 1981 with very well defined set of OS entry points making it transparent to code running in one ROM to call code living in another ROM in the same address space ($8000-$BFFF) This removed the limitation of having it's somewhat small (at the time) 32KB RAM.

So a "language" (e.g. BASIC or a Word processor) could call a disc or network filing system or utility (e.g. printer driver or speech chip) that lived in the same ROM region with confidence that the underlying OS would do the right thing for it and return back to where the call originated from.

Not everyone obeyed the rules but those were exceptions - typically games which tended to take over the whole machine anyway.

The C=128, some 4 years after the BBC Micro could have copied some of these ideas but I suspect their goal to maintain compatibility with earlier models was the limitation there.

-Gordon

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

Thanks all.

What seemed to be a mess was the Commodore CBM-II line of machines, that would be able to drive natively up to 1MB of RAM, but had a terrible bank switching system. Certain things could be done only in certain banks. But I'm telling here what I heard from someone trying to program it, with not that experience programming a 6502.

The '134 and the '265 do share that feature of being able to select the region of the ROM you want to work with.

I was thinking yesterday that another way to have this done would be to design the computer in a way that when booted, the $C000-$FFFF would be actually all ROM, and the first thing the computer would do is to copy code contained in that ROM to RAM in $0300 and jump there.

And what the code would be just disabling the ROM and enabling the Bank 0 of the 256K RAM chip.

But that's only an idea.

It has been said that with quality code and for the things done with the 65xx architecture 64K are enough if you don't want to do complicated stuff, like being a desktop computer like the ones in those years (Commodore, Apple, BBC and so).

What I'm asking is that maybe the idea of having banks of 32K would be maybe too much, and it would be better to have more banks of smaller size. That way, instead of eight banks of 32K, there would be sixteen banks of 16K, or even thirty-two banks of 8K... And with clever design, there could be mapped to different areas at the same time and copy data between them, or run code in one and have data in the other one.

Once again, I'm theorizing here instead of having a project, so everybody is more than welcome to participate.

Back to the desktop computer example, an useful thing could be that the user would want to load a GEOS like environment. The main code would reside in the first 32K of RAM, where certain common routines and code would be stored like... drawing windows, printing or whatever.

And when the programs like a word processor, spreadsheet, calculator or anything else would be loaded, they would go to different banks that would had stored the code to run them.

With a memory setup of 32K (LOW) + 16K (HIGH1) + 16K (HIGH2), there could be two different banks with different code that could be exchanged as needed, so different combinations could be made as needed: LOW would be fixed RAM in its own chip. but HIGH1 and HIGH2 could by any of the different banks offered by the 256K chip, selected as desired.

Or even 32K(LOW) + 8K (HIGH1) + 8K (HIGH2) + 8K (HIGH3) + 8K (HIGH4).

The thing is that the 6502 will run what ever you put it to, and it's the hardware design and the programmer ability what unleashes its potential.

Again... what do you think?

Thanks, again.

I think you might end up with another BBC Micro - which is sort of what I've ended up with, although no-where near as good in my case - different though.

The Beeb is described elsewhere, but briefly; 32KB RAM the top portion being variable size from 1KB to 20KB used for video, then 16KB of banked ROMs (latterly RAMs) then 32KB of OS (with a 2KB gap for IO).

The original idea and progression of the Beeb was that the base unit, while a computer in its own right would end up as the IO processor to the real CPU which was attatched by a high speed device (The Tube) - so the first Tube CPU was another 6502 running at 3Mhz which gave you almost 60KB of RAM to use. Other CPUs followed - eventually culminating in the Acorn RISC Machine (ARM), then Acorn migrated to an ARM based computer (Archimedes, etc.) before the x86 won the 'desktop wars' ...

Cheers,

-Gordon

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

Indeed, it's common enough to have ROM mapped in at reset, copy to RAM, and then by some mechanism or other, disable that ROM.

@hoglet added an 8k bank-mappable model into the Matchbox copro for the BBC Micro and also into one of the 6502 models in PiTubeDirect. I was somewhere in the vicinity of this. And likewise, we (or he) cooked up a version of Conway's Life which makes use of the mapping to access a very large data structure. So that's an application. You can read about all this here. And there's a video here.

Another nice way to use lots of memory is with an operating system which knows how to use it: Fuzix supports several platforms and has had a 6502 port at points in the past. It copes with various memory mapping schemes. Edit: see here perhaps.

And it's easy enough to imagine swapping out more or less wholesale in order to task-switch between different tasks running conventionally, although I'm not sure I've seen it done.

For some purposes, a large data area is enough, either because the code is small or because the code is interpreted and therefore actually data. Acorn's 256k machine works by offering data-only access to a large memory space. That too is now available as an option in PiTubeDirect. See here and here.

Edit: there are, or were, also 6502 variants offering extended data access, as used in some photo keyrings. And the Apple III had an interesting memory map, as I recall. See here.

Edit: and Jeff's KimKlone has (or had) extended addressing; he can perhaps chip in to tell us how he made use of that.

One thing I've thought about is having smaller 8k windows so you can have at least 3 pointers going at once. 2 might be enough but 3 let's you take in 2 inputs and output the result somewhere else. With 16k banks, you only have 2 that are full size since one loses space to the stack and the other to vectors. The 8k banks can also be made contiguous if 16k banks are needed.

No doubt, 8 slots of 8k feels quite neat and flexible. And in an emulator or FPGA it's pretty simple. But in TTL it starts to look like a subsystem... perhaps there's a neat way to do it.

If you want banking without too much glue logic, you put the register selector in an EPROM and have its 8-bit output coupled to a latch which controls the SRAM higher bits (e.g. Address lines A16-A23). How you connect the data and address lines from the 6502 towards the EPROM is up to you.

I was thinking about that, too, but one thing that I believe is that the change of bank should be effectively done in the low half of the cycle, to have it available the next high cycle of the CPU.

If I use an EPROM like you said, it will be working in sync with the CPU.

Am I right?

I just ordered a couple of 6502 to try to test this.

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

Note that any system that uses ICs from this century, is a fast (high-frequency) circuit (on the order of hundreds of MHz); modern chips have very fast transition times, thus introducing high frequencies. A slow clock simply triggers your high-frequency circuit every now and then...

P.S. Doesn't matter much in this case, but it's good to remember there aren't many slow systems...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut