6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 9:46 am

All times are UTC




Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed May 05, 2021 5:03 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
tokafondo wrote:
But if PC >=$8000, and the code there changes the bank, then the next instruction wouldn't be the expected one because all what is contained in $8000-$FFFF in different from what was there previously...

...unless what is stored in the new bank is the right instruction to be processed, because that's how it was coded.

Clearly, code running in the upper 32KB would be cruising for a bruising and would likely trigger a crash if it decided to change the memory map. It was this sort of thing that made cross-bank subroutine calls in the C-128 somewhat risky.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 6:36 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
tokafondo wrote:
BigEd wrote:
Why did you mention PC < $8000?


The banking system I'm thinking about works by replacing the whole high 32K area everytime a bank is switched out.

What the 6502 would be seeing is the low 32K being always the same. And the high 32K would change completely when the bank registers are changed.

So: if PC <$8000, then no matter how many times the high 32K changes, the next instruction to be processed would be the expected one.

But if PC >=$8000, and the code there changes the bank, then the next instruction wouldn't be the expected one because all what is contained in $8000-$FFFF in different from what was there previously...

...unless what is stored in the new bank is the right instruction to be processed, because that's how it was coded.


Yes indeed, this matches my understanding of what happens.

I see my confusion now: I'd misunderstood what you wrote. You said:
Quote:
That enabling should be made by writing a four bits register. That register would be a latch or flip-flop chip that would be kept static that until reset or changed by the CPU. Those four bits should be maped in location that would fall in the first 32K bank of memory, and should be changed only when the program counter would be pointing to an address =<$7FFF, unless extreme careful programming would allow for switching banks and having code there that would continue running with no problems.


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.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 7:11 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
I think it's worth mentioning André Fachat's CS/A65 CPU board containing a 74LS610 based MMU.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 8:42 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
tokafondo wrote:
When booting the 6502, there must be RAM in $00-$FF. And there should be also RAM in $100-$1FF for programs work reliably. (*)

And there should be somethingthat the CPU could read in $FFF0-$FFFF. Either ROM, or RAM with the appropiate locations filled with values, put there before kickstarting the CPU.

I was wondering about having the 6502 access the first 32K of memory as fixed RAM, and then bank the other 32K with the flip of a switch.

The fixed RAM would be where the main code of an app, game or OS would be. There would be also mapped inside access to things like storage and different chips like serial or parallel ports, sound and graphics, through the use of registers that would be inside those first 32K.

And the following memory from 32K up to 64K would be swappable, and would contain data that the code running in the first 32K could use. Or even more code that wouldn't be running all the time but only when needed.

What would be that chip that would allow for a redirection of the top 32K? Some kind of memory selector?


(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/


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 9:14 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
BigDumbDinosaur wrote:
Clearly, code running in the upper 32KB would be cruising for a bruising and would likely trigger a crash if it decided to change the memory map. It was this sort of thing that made cross-bank subroutine calls in the C-128 somewhat risky.[/color]


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/


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 11:21 am 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 344
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 12:13 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
tokafondo wrote:
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/


Top
 Profile  
Reply with quote  
PostPosted: Wed May 05, 2021 12:20 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 1:34 am 
Offline
User avatar

Joined: Mon May 12, 2014 6:18 pm
Posts: 365
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 7:32 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 10:24 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
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. :wink:


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 6:08 pm 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 344
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 6:09 pm 
Offline

Joined: Sat Apr 11, 2020 7:28 pm
Posts: 344
I just ordered a couple of 6502 to try to test this.


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 8:57 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
kakemoms wrote:
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. :wink:

What you are describing is what we used to call poor-man's programmable logic. Fun fact: when Lloyd Sponenburgh designed the hardware prototype for what would become the Xetec Lt. Kernal, he implemented the host adapter logic in two EPROMs. Production units used Intel UV-erasable PLDs that were basically souped-up EPROMs.

There are two possible problems with using EPROM logic. The obvious one is system performance will be constrained. Currently-available EPROMs are no faster than 70ns and EEPROMs are typically slower. For some perspective, 70ns is approximately equal to the propagation delay of eight to ten cascaded 74AC gates running at five volts. Even if you were to use something such as a Microchip 27C256-45, which is actually a PROM, not an EPROM, you'd still have the prop delay of five to six cascaded 74AC gates. Furthermore, the required latch will add to the EPROM's access time, making for even slower response.

The other, more-insidious, problem is glitching. Many EPROMs do not cleanly change their D0-D7 outputs when address inputs change while /CS and /OE are simultaneously asserted. Instead, random data momentarily appears, which could cause improper device selection or even result in two devices being simultaneously selected.

Given that genuine PLDs are readily available and don't glitch their outputs when their inputs change, I would not consider the "poor-man's PLD" route a good one, except in a system that runs very slowly.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu May 06, 2021 10:17 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
BigDumbDinosaur wrote:
..except in a system that runs very slowly.


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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 68 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: