6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Nov 13, 2024 10:04 pm

All times are UTC




Post new topic Reply to topic  [ 133 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 9  Next
Author Message
PostPosted: Sun Oct 06, 2013 8:58 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
GARTHWILSON wrote:
Quote:
Regarding the '154 decoder, you should know that it is relatively slow device. Unless you truly need more than eight I/O slots in your design you should consider using the faster (and physically smaller) '138. Naturally, your glue logic should be 74AC or 74HC, not 74LS.

This reminds me I never did answer your earlier question about what year my NSC CMOS logic data book was from. The answer is '88...

That explains some of the performance data you've mentioned. Fortunately, chip technology has advanced a bit from those days. :D

Quote:
...and it has the '154 at about the same speed as the '138, both kind of slow-- but it may not matter much if he's going to run the circuit slowly enough for the SID. The '154 in CMOS is in a .300"-wide skinny DIP, unlike the TTL and LSTTL ones which were wide, so the CMOS one takes about as much room as one and a half 138's.

Uh, forgot about the SID. It has to run at a constant 1 MHz, so the ultimate system speed is going to be limited no matter what. As you've said before, you can get away with murder at 1 MHz.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 06, 2013 9:01 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
Rob Finch wrote:
Quote:
The first 1k or 2k would always be bank 0 while the rest is bankable.


I'd be tempted to make that address range bankable too. Then it might be possible to run multiple programs which use the area.

I placed all my I/O high up in memory at the range $FFDxxxxx for my system (32 bits).

You'd have to make sure that a valid ISR vector exists at $xxxxFFFE no matter what, and that vector had better be pointing to an ISR, no matter what. Otherwise, the reset push button will get worn out.

It all sounds like way too much complexity to me. Of course, I'm just a curmudgeon... :lol:

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 06, 2013 9:35 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
BigDumbDinosaur wrote:
GARTHWILSON wrote:
Quote:
Regarding the '154 decoder, you should know that it is relatively slow device. Unless you truly need more than eight I/O slots in your design you should consider using the faster (and physically smaller) '138. Naturally, your glue logic should be 74AC or 74HC, not 74LS.

This reminds me I never did answer your earlier question about what year my NSC CMOS logic data book was from. The answer is '88...

That explains some of the performance data you've mentioned. Fortunately, chip technology has advanced a bit from those days. :D

I think you gave a link to the TI 74HC138 data sheet before and said it was about 15ns max; but I'm looking at http://www.ti.com/lit/ds/symlink/cd74hc138.pdf (their current 74HC138 data sheet) which says that at 6V, 50pF load, -40 to +85 deg C, the max is 33ns, and http://www.ti.com/lit/ds/symlink/cd74hc154.pdf (their current 74HC154 data sheet) which says that at the same voltage and temperature range the max is 37ns. 5V will make it a tad worse, but 25 deg C will make it a tad better. There will be small variations between brands, but these are approximately what my '88 data book said. I expect they will keep any given family about the same, but as technology advances, they have introduced new families.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 06, 2013 11:08 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
Thanks for all your replies!


GARTHWILSON wrote:
The keyboard, joystick, beeper, RTC, I²C, and maybe other stuff too can all go on one VIA.
yes, I saw that design of yours, I wouldn’t come up with something like that on my own, so I planned some headroom.

GARTHWILSON wrote:
That's one of the things ElEctric_EyE started with, then he kicked the clock rate up after the copying.
I definitely want to include a variable and from software selectable clock.

GARTHWILSON wrote:
If you do not try to have program material in multiple banks, the difficulty I mentioned further up goes away.
That was my intention, 32k of program space is way enough for my skills.

BigDumbDinosaur wrote:
6502 (which device I don't recommend you use) / Getting back to my comment about not using a 6502, I would not use NMOS hardware on any new design. If you want to stay with the 6502 you should use the more technically advanced W65C02S (not the Rockwell pulls that are floating around on eBay or at Jameco). WDC's CMOS processors are efficient low power, high performance devices that are superior in every respect to the NMOS equivalents. The PDIP-40 version of the 65C02 is a drop-in replacement for the 6502 (with one caveat). Errata in the NMOS parts have been corrected (e.g., the infamous JMP ($xxFF) bug) and new instructions (some very useful, such as PHX and PLY) have been added. Also, the NMOS part has some odd hardware behavior that can cause false chip accesses at inopportune moments if the circuit isn't carefully designed.
I thought I have 2 or 3 lying around doing nothing, so why not using them. But considering all this, I’ll have to agree.

BigDumbDinosaur wrote:
The acrobatics required to use banked RAM with the 6502 are considerable. You need only to look at the Commodore 128 to see what I mean.
I absolutely agree, programming in ML on the C128 is not that much fun. I’d rather use BASIC V7.0. Well, except for the lack of speed.

BigDumbDinosaur wrote:
Naturally, your glue logic should be 74AC or 74HC, not 74LS.
You don’t mention 74HCT for a reason?

GARTHWILSON wrote:
The '154 in CMOS is in a .300"-wide skinny DIP
actually my supplier does have both, .300” and .600” DIP.




Most of you are advising me to use an ‘816. I’m open to that suggestion, but I have some concerns.

First of all, banking would be just a nice addition, certainly not a necessity (to me at least). I’ll be using a Gameduino for VGA out. At startup, I have to write a charset to it.

In order to familiarize myself with the ‘816, I would like to see a few different schematics of some SBC’s. Like yours and BDD’s POC. I don’t know if they are online, but if they do, I’ll find them. Are there any other’s online?

I’ve started to read the ‘816 datasheet and it looks rather impressive.

I’d really like to include a 6581 SID and a 8580 SID, they have to be in there! However, it would be silly to run the whole system with 1MHz. Can they be implemented if the system is running on a higher clock (2,4, or 8MHz.)? I’m pretty sure that PHI2 of the SID has to be (around) 1MHz. What about R/W? I will make a variable clock with a selection register and run it at 1MHz. while using the SID. But that’s not so elegant. Does R/W operate at 2 MHz. at “FAST MODE” on the C128? Does any one of you have a SID in your SBC? I know the KIWI has. It runs at 10MHz but has an E output.

Another concern are MOUSER’s ridicules shipping costs (20 euros). I’m living in the south of the Netherlands near the German border, so I could order from both countries.

I understand for higher clock speeds I need either AC logic or CPLD. My “bug vendor” has only 18 different AC chips and some of them are SMD at 1.27mm pitch. That’s probably doable for me. CPLD wise I’m a total beginner. Just knowing that it can replace TTL and is pretty fast. I’m building a simple CPLD parallel port programmer and a test board with an XC 9572XL PC44 at the moment.

If I’m going to build my SBC (MARC-2) around an ‘816 I’ll be having far more questions than when I choose a 65(C)02. I’d be heavily depending on your help and advice. And progress will in any case be slow due to my illness.

So for my first SBC I’d skip some steps and experiences.

Edit1: found BDD's POC schematics. Nice!

_________________
Marco


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 12:56 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
GARTHWILSON wrote:
think you gave a link to the TI 74HC138 data sheet before and said it was about 15ns max; but I'm looking at http://www.ti.com/lit/ds/symlink/cd74hc138.pdf (their current 74HC138 data sheet) which says that at 6V, 50pF load, -40 to +85 deg C, the max is 33ns, and http://www.ti.com/lit/ds/symlink/cd74hc154.pdf (their current 74HC154 data sheet) which says that at the same voltage and temperature range the max is 37ns. 5V will make it a tad worse, but 25 deg C will make it a tad better. There will be small variations between brands, but these are approximately what my '88 data book said. I expect they will keep any given family about the same, but as technology advances, they have introduced new families.

See attached, which is a current NXP (formerly Phillips Semiconductors) 'HC138 data sheet.
Attachment:
File comment: 74HC138 3-8 Decoder
74hc138_decoder.pdf [205.9 KiB]
Downloaded 60 times

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 4:36 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
Quote:
See attached, which is a current NXP (formerly Phillips Semiconductors) 'HC138 data sheet.

So they're similar. Page 7 has the HC showing 38ns max at 4.5V and 33ns max at 6V, 50pF load and -40 to +85°C, and page 8 the HCT showing 50ns max for HCT at 4.5V, same load and temperature range.

http://www.ti.com/lit/ds/symlink/cd74ac138.pdf shows the 74AC138 having 10ns worst case at 5V, 50pF, -40 to +85°C, which finally makes the '138 suitable for much higher operating speeds. If there were an ABT138, that'd be the cat's meow, but I haven't found one available. I've been able to find and buy several different ABT's since you alerted us to them, but alas, many in the family are not available in ABT. One I'd sure like to find is the '521 or '688 8-bit equality detector. Address decoding would be a major application.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 5:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
lordbubsy wrote:
You don’t mention 74HCT for a reason?

ACT and HCT inputs are TTL-level compatible to allow an LS device to drive a CMOS device. If everything is CMOS (which it should be in new designs) there's no need to use ACT or HCT. Incidentally, 74ABT logic, despite the name, is CMOS. It features single nanosecond performance and high drive strength. You'd only use it if you were trying to take a 65C02 or 65C816 all the way up to 20 MHz.

Quote:
Most of you are advising me to use an ‘816. I’m open to that suggestion, but I have some concerns.

We have answers...mostly. :lol:

Quote:
First of all, banking would be just a nice addition, certainly not a necessity (to me at least).

A bit of technical pedantry: "banking" in the 65C816 sense is nothing like what you would see in a C-128. The C-128 was dependent on the actions of the 8722 MMU and the PLA (which was most of the C-128's glue logic) to select one 64KB bank or the other, maintain a common area at low RAM, and map ROM and I/O in or out as needed. The ability to configure a common area was de rigueur as without it, bi-directional cross-bank transfers were all but impossible (BASIC would not have been able to run). Also, the C-128's kernel had to write some ISR front-end code into both RAM0 and RAM1 to assure that the 8502 would have a place to land when an interrupt occurred. That code had to push the registers, read the MMU configuration at $FF00 and push it, and then write $00 to $FF00 to map in the kernel ROM. It was a complicated and somewhat fragile arrangement with which I got very familiar back when I professionally programmed that machine.

In contrast, the 65C816 can address a full 24 bits of RAM with minimal glue logic (a 74AC573 or 74ABT573 latch to drive A16-A23 from D0-D7 and an out-of-phase clock to gate the '573) and without the need for common RAM areas. Several ways are available to access the entire 16MB space without any special steps, including using a 24 bit direct page (aka zero page) pointer. When an interrupt hits, the '816 will go back to (program) bank $00 to fetch the ISR vector and start executing the ISR without the rest of the hardware having to do anything special. When the ISR RTIs, the '816 will return to the bank in which it was executing when the interrupt hit, again without the system logic having to do anything special. That is all in stark contrast to the hoop-jumping done by the C-128, and is much simpler than trying to make a 65(c)02 address more than 64KB.

That said, you aren't obligated to use the A16-A23 address component at all, and can completely ignore it like I did with my POC V1 units. As long as the glue logic is correctly implemented, the '816 will pretend it only knows about a 16 bit address bus and will behave like a 65C02 on a big dose of steroids. You can run the '816 in emulation mode (the default at power-on or reset) until you get comfortable with your system, and then start exploring native mode and 16 bit programming. Once you get some experience under your belt with this hardware you can design version two with A16-A23 decoding hardware and rig up as much RAM as you want.

Quote:
I’ll be using a Gameduino for VGA out. At startup, I have to write a charset to it.

You'd do that in your reset handler. That's basic I/O. What are you going to use to read a keyboard?

Quote:
I’ve started to read the ‘816 datasheet and it looks rather impressive.

That's because it has more features than the 65C02. Don't let it scare you. Ninety percent of the assembly language is the same. The other ten percent is where the '816 really differentiates itself from the 'C02.

Quote:
I’d really like to include a 6581 SID and a 8580 SID, they have to be in there! However, it would be silly to run the whole system with 1MHz. Can they be implemented if the system is running on a higher clock (2,4, or 8MHz.)? I’m pretty sure that PHI2 of the SID has to be (around) 1MHz. What about R/W? I will make a variable clock with a selection register and run it at 1MHz. while using the SID. But that’s not so elegant. Does R/W operate at 2 MHz. at “FAST MODE” on the C128? Does any one of you have a SID in your SBC? I know the KIWI has. It runs at 10MHz but has an E output.

That's not going to be a trivial thing to implement. The usual method of interfacing a slow peripheral device to a fast system is to use wait-states to temporarily halt the MPU. When the MPU is wait-stated by asserting (negating) the RDY input, it stops execution of the current instruction and holds all signals that it is driving in the state they were in when the wait-state started. The wait-state gives the slow device enough time to respond to inputs and do what it is supposed to do. Upon release of RDY, the MPU will resume execution of the current instruction.

Unfortunately, none of the NMOS versions of the 6502 (including the C-128's 8502) will respond to RDY when the current operation is a write. This shortcoming was addressed in the C-128 by implementing a hardware feature referred to as clock-stretching, resulting in all accesses to the I/O block ($D000-$DFFF) occurring at an effective 1 MHz rate, no matter the MPU frequency. Clock stretching temporarily increases the effective clock period to one microsecond during actual chip access, which allowed Commodore to use the 6581 without alteration (also true for the two 6526 CIAs).

As both the 65C02 and 65C816 will halt on a write cycle when RDY is asserted, you can use wait-states to access the SID. The device's Ø2 input would have to be phase-synced with the MPU's Ø2 clock so when the MPU is wait-stated on a SID access the latter's clock is in a high state. You could do this with cascaded flip-flops to divide the MPU's Ø2 clock to 1 MHz. The flops would have to be very fast to avoid having the SID's clock get significantly out of phase with the MPU's clock. I envision that you'd have to use programmable logic to achieve all this. Attempting to do it with discrete logic will likely result in too many cascaded propagation delays.

Aside from the timing issues, getting a 6581 (NMOS) or 8580 (HMOS) operating on a bus driven by a CMOS MPU will present a problem or two. As is typical of devices of that era, the SID has weak fanout, so direct connection to a data bus full of other hardware may not work, forcing you to use an octal transceiver to "boost" the SID's output. I don't know if anyone has tried such a thing, so you might be breaking new ground here.

Quote:
Another concern are MOUSER’s ridicules shipping costs (20 euros). I’m living in the south of the Netherlands near the German border, so I could order from both countries.

€20 does seem steep for shipping small parts that weigh a fraction of a kilogram. Perhaps some forum members who live in your area could offer suggestions on obtaining parts.

Quote:
I understand for higher clock speeds I need either AC logic or CPLD.

The fastest discrete logic available today is 74ABT. Some gates are as fast as 3ns. Unfortunately, 74ABT isn't available in all logic types, so your next bet is 74AC. You can use 74HC if you don't plan to ramp up the clock too much. A simple system with 74HC might be able to make it to 8 MHz, but that 125ns cycle time will be getting tight. You have to keep in mind that the MPU is doing stuff on both halves of the clock cycle and that read/write access occurs only during Ø2 high. That's 62.5ns at 8 MHz. I've "stress tested" my POC unit at 15 MHz (without access I/O) and know that it wouldn't be able to run that fast with 74HC logic.

PLDs are available at 10ns and faster, which is a pin-to-pin prop time (internal gate prop times are not additive in the usual sense). A reasonable system can be built around a 10ns GAL, such as a 22V10, with the GAL handling I/O decoding and wait-states. You'll run out of resources with a GAL if you get much more complicated. That's where a CPLD becomes attractive.

Quote:
My “bug vendor” has only 18 different AC chips and some of them are SMD at 1.27mm pitch.

1.27mm (0.050 inches), also referred to as SOIC, can be hand soldered. My POC V1.1 unit has an SOIC SRAM and SOIC form of the MAX-238 transceiver. The SRAM has J-leads and the MAX-238 has "butterfly" leads. Despite the close pitch, my not-so-steady hands and less-than-sterling eyesight, I was able to solder both without any trouble. I discuss the technique on my POC website. There are also some videos on U-Toobe that illustrate various techniques.

Quote:
CPLD wise I’m a total beginner. Just knowing that it can replace TTL and is pretty fast. I’m building a simple CPLD parallel port programmer and a test board with an XC 9572XL PC44 at the moment.

A CPLD is just a whole lot of gates in a single die, so if you understand the use of discrete logic, you are half way to getting a CPLD to work for you. The languages used to program CPLDs (CUPL, VHDL, etc.) do most of the hard work for you.

Quote:
So for my first SBC I’d skip some steps and experiences.

I and others around here always advise first-time builders to exercise restraint in developing a homebrew computer. Trying to incorporate too many features and/or an idiosyncratic memory map into the design almost guarantees that the unit with be DOA on first power-up and difficult to debug. In other words, it's best to learn how to pilot a single-engine light plane before stepping into the cockpit of a 747 or A380.

Quote:
Edit1: found BDD's POC schematics. Nice!

Excellent. My website is due for more updating but time has not allowed me to do a long burn on it. The schematics you found, however, contain the hardware bug-fixes that corrected timing issues that popped up in the initial unit (V1.0).
-----------------------
Edit: I attached the schematics for POC V1.1, which are more up to date that the schematics you found. As I said, I need to update the website. I omitted the SCSI host adapter schematic.
-----------------------
Attachment:
File comment: POC V1.1: Memory Map
sbc_v1.5.2_p1.gif
sbc_v1.5.2_p1.gif [ 113.66 KiB | Viewed 836 times ]

Attachment:
File comment: POC V1.1: Microprocessor Interface
sbc_v1.5.2_p2.gif
sbc_v1.5.2_p2.gif [ 151.93 KiB | Viewed 836 times ]

Attachment:
File comment: POC V1.1: RAM, ROM & I/O
sbc_v1.5.2_p3.gif
sbc_v1.5.2_p3.gif [ 115.48 KiB | Viewed 836 times ]

Attachment:
File comment: POC V1.1: External Interface
sbc_v1.5.2_p4.gif
sbc_v1.5.2_p4.gif [ 94.53 KiB | Viewed 836 times ]

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


Last edited by BigDumbDinosaur on Mon Oct 07, 2013 5:52 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 5:15 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
GARTHWILSON wrote:
Quote:
See attached, which is a current NXP (formerly Phillips Semiconductors) 'HC138 data sheet.

So they're similar. Page 7 has the HC showing 38ns max at 4.5V and 33ns max at 6V, 50pF load and -40 to +85°C, and page 8 the HCT showing 50ns max for HCT at 4.5V, same load and temperature range.

You can see the effect of having that extra bit of circuitry at the HCT device's input in the speed reduction.

Quote:
http://www.ti.com/lit/ds/symlink/cd74ac138.pdf shows the 74AC138 having 10ns worst case at 5V, 50pF, -40 to +85°C, which finally makes the '138 suitable for much higher operating speeds. If there were an ABT138, that'd be the cat's meow, but I haven't found one available. I've been able to find and buy several different ABT's since you alerted us to them, but alas, many in the family are not available in ABT. One I'd sure like to find is the '521 or '688 8-bit equality detector. Address decoding would be a major application.

I've found no references anywhere to an ABT version of the '138. Most of the ABT logic is in basic gates and bus drivers/transceivers, the latter being an application where the ABT logic really pays off.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 9:59 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
The important thing about the 816 is that it's almost pin-compatible and it boots into a 6502 mode.

I'd advise against increasing the scope of your project to accommodate all the features of the 816 - it's the kind of thing which gets in the way of finishing anything (or even starting anything)

So, by all means buy the 816, but do build an 8-bit system first! And stick to 8-bit software, until you have something running.

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 7:54 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
BigEd wrote:
The important thing about the 816 is that it's almost pin-compatible and it boots into a 6502 mode.

I'd advise against increasing the scope of your project to accommodate all the features of the 816 - it's the kind of thing which gets in the way of finishing anything (or even starting anything)

Exactly. You've essentially described POC V1.0. Version 1.1 merely rolled in the hardware patches and added some circuitry needed to take advantage of the SCSI controller's DMA channel. If the SCSI host adapter is unplugged and the Dalla watchdog is plugged into the "expansion port," the unit will boot directly into the M/L monitor and will look like V1.0 (minus the bugs).

Quote:
So, by all means buy the 816, but do build an 8-bit system first! And stick to 8-bit software, until you have something running.

Your advice is correct, of course.

As I had said, I ran POC V1.0 in eight bit emulation mode for quite some time before switching to native mode and rewriting the BIOS into 16 bit code. I first fired up the unit in December 2009 and didn't permanently switch it to native mode until August 2010, by which time all known hardware errata had been eliminated and most, if not all, bugs in the firmware had been corrected. The switch to native mode operation was also when I recoded the BIOS to take advantage of 16 bit operations. I haven't looked back since. :D

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 9:19 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
So, has any one given any thoughts to a 65816 memory map, considering the CPU vectors are at the top of the first data bank.

Lot of talk about a 6502 8 Bit map, but, what were you thinking BDD for v2.0 with 4MB of RAM? Were you planning on leaving Bank 0 alone, or solely for the supervisor, and load all of the user space above it?


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 10:01 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
Sorry for the delay but I will respond properly tomorrow...

_________________
Marco


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 10:24 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
Hrm, 65816 D and S registers are both 16-bit, and constrained to bank 0, so that should be mostly-to-completely RAM... Or something stupid-clever, such as making it ROM for interrupt-vector and code fetches, and RAM for data operations. Mirror the ROM somewhere higher up in the address space as well, and possibly use a resettable latch to control the overlay of the ROM into the RAM space...

The RESET sequence would basically be CLC, XCE, JML to ROM space, then something to hit the latch to allow executing code from RAM. No fuss, a little muss, a contiguous RAM region at the bottom of the address space, a decent-sized ROM region (I'd use sst39sf040 512kx8 ROMs), and there's plenty of open room for I/O.

That's a first approximation, of course, I haven't really thought about it too deeply, or about the consequences of not having I/O in bank zero (where it could be twiddled by dpage instructions), or about precisely how to implement the address decoding logic.


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 07, 2013 11:12 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
nyef wrote:
Hrm, 65816 D and S registers are both 16-bit, and constrained to bank 0, so that should be mostly-to-completely RAM... Or something stupid-clever, such as making it ROM for interrupt-vector and code fetches, and RAM for data operations. Mirror the ROM somewhere higher up in the address space as well, and possibly use a resettable latch to control the overlay of the ROM into the RAM space...

Samuel Falvo had a clever way to do something like that. Can anyone remember some search terms to find it?

Note however that direct pages and the hardware stack together do not need very much of bank 0. Even if you have many tasks running at once that have their own DP, as long as they don't need anywhere near a whole page each, those direct pages can overlap without stepping on each other. The same goes for individual tasks' stack spaces.

Quote:
That's a first approximation, of course, I haven't really thought about it too deeply, or about the consequences of not having I/O in bank zero (where it could be twiddled by dpage instructions), or about precisely how to implement the address decoding logic.

I asked about having I/O in a bank other than bank 0 at viewtopic.php?f=4&t=1484 and there was some discussion there.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 08, 2013 1:12 am 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
I usually just let the I/O decoding appear in all 256 banks. It does waste a 2k or 4k block in each bank but it make access of IO from each bank much easier.


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 20 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: