6502.org Forum Projects Code Documents Tools Forum
It is currently Thu Nov 21, 2024 10:01 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 1 of 2
  [ 26 posts ]  Go to page 1, 2  Next
  Previous topic | Next topic 
Author Message
GARTHWILSON
 Post subject: I/O not in bank 0
PostPosted: Tue Dec 08, 2009 10:57 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
I'm finally getting more serious about building my next workbench computer, using the 65816 with 4MB (64 banks) of SRAM, and I see a way to make my glue logic for all address decoding and chip selects trivially simple and very fast (7ns typ, 12ns max, without programmable logic) if I put the I/O from address 40:0000 to FF:FFFF. SRAM goes from 00:0000 to 3F:FFFF, and the reset vector and boostrap loader get pre-loaded into RAM before the processor is released for start-up.

I have to choose between A., the fast logic which will allow faster clock speeds, and B., the disadvantages of having to use long addressing for every I/O access. The latter not only means three-byte operands and an added clock cycle, but also the fact that some "long" op codes are missing, most notoriously BIT. (INC and DEC are nice too when you just want to change bit 0 of an output port. Those are missing as well.) The indirect and indexed longs have less application in I/O, so I don't see them as an issue.

It seems like someone here has mentioned putting their I/O someplace other than bank 0, but I can't remember who, or remember what to search for. If you've done it, what grade would you give the result? Would you do it again? I'm trying to weigh the hardware advantages with the programming disadvantages and get a feel for the net outcome.

_________________
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  
8BIT
 Post subject:
PostPosted: Tue Dec 08, 2009 1:35 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Garth,

I just posted that I have moved my IO from zeropage to bank $08.

yes, you are right in that it adds more cycles to complete access. I have not tested the throughput yet, but I will soon.

The biggest thing I had to change was the use of
Code:
 
  SPIATM8 = $40  ; bit 6
 
  LDA  #SPIATM8       ; 2 cyc - 2 bytes
  TRB  $22            ; 5 cyc - 2 bytes

to change the SPI device select. Now its
Code:
   LDA #255-SPIATM8   ; 2 cyc - 2 bytes
   AND $080022        ; 5 cyc - 4 bytes
   STA $080022        ; 5 cyc - 4 bytes


Thats a big change in terms of cycles and program space. Granted, I was using zero page vs an absolute address in bank 0 so the change from absolute to bank>0 will be a little less drastic.

As a benchmark, I will transfer a large file via RS-232 and my CF storage system, both via SPI, using the zeropage addressing and bank 8 addressing, and will report the times back.

Daryl
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Tue Dec 08, 2009 7:24 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Thanks Daryl. I didn't realize it was so recent. That was only to free-up more bank-0 RAM though, and was not really associated with your raising the clock speed, right? But you might still have a similar evaluation to make, seeing if the availability of more bank-0 RAM improves performance enough on largish applications to justify having the I/O in bank 8? Even though I'm planning for 64 banks of RAM, the non-bank-0 RAM will be for data, not executable program. Exceptions will be rare.

I was forgetting about TRB & TSB which you mention. I was thinking mainly of input, where you can test bits 6 and 7 with the BIT instruction in a single instruction without affecting A, X, or Y, and follow the BIT by a conditional branch on the N or V flag.

Anyone else putting their I/O in another bank? Or even if you haven't done it yet, have you figured out any neat tricks to partially get around what seem to be sure drawbacks? Or even found any more not-so-obvious problems it presents?

_________________
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  
BigDumbDinosaur
 Post subject: Re: I/O not in bank 0
PostPosted: Thu Dec 10, 2009 3:32 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
I'm finally getting more serious about building my next workbench computer...I see a way to make my glue logic for all address decoding and chip selects trivially simple and very fast...if I put the I/O from address 40:0000 to FF:FFFF. SRAM goes from 00:0000 to 3F:FFFF...

Wouldn't that scheme effectively limit you to 4 MB of RAM with no possibility of further expansion?

Why wouldn't you want to use a PLD to produce a more robust decoding? Just curious.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Thu Dec 10, 2009 6:46 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
Wouldn't that scheme effectively limit you to 4 MB of RAM with no possibility of further expansion?

Yes, but there don't seem to be any bigger asynchronous SRAMs in our future—ever. There have been 2Mx8's for several years in 3V, but I think there are still too many things I want the computer to interface to in 5V, so I think I'll stay with 5V. The 65816 will run faster at 5V anyway. With 512Kx8 SRAMs which are the biggest I can find in 5V, 4MB would require 8. I can stack them about 3/4" tall so they only take one socket, and put a 74ACT138 on it which is great with its three enable inputs plus of course the three output-select inputs and 8 outputs to connect one to each SRAM's CS\. [Edit: I now have my 4Mx8 5V 10ns SRAM modules available. See the front page of my website, linked at the bottom of this post.] Cypress is introducing a SRAM chip that's 4Mx8, but it's in BGA, not even SOJ or SOIC, and I don't know that I would ever be able to mount it by hand. If you know a way to do it, I'd like to hear it. It might be good news even though the part is 3V. I could put three of those on a socketable part and have 12MB of SRAM.

I was pleased to find out that that much bus loading (from 8 SRAMs) won't have nearly the effect on speed as I had thought. Still, I don't think I want to put 16 or 24 SRAM chips on the bus. I'll stop at 8.

The 4MB allows me 2MB of look-up tables for fast 16-bit scaled-integer/fixed-point math [edit, June 2012: now available at http://WilsonMinesCo.com/16bitMathTables/index.html ]. For example, looking up a cosine or logarithm will take only a couple of microseconds to get all 16 bits correct, with no calculation required. Even for division, I can look up a 32-bit reciprocal to multiply by, and the multiplication is sped up with look-up tables too. I already have all these tables calculated and formed in Intel hex files. Ideally these would be in ROM, but ROMs' speed is very slow compared to the 10ns SRAMs I'm about to order. The tables will have to be loaded from files in serial flash memory on the 65SIB.

I would probably always load the lookup tables for multiply and divide (reciprocal to multiply by), but most applications wouldn't need the others. That would leave 2MB to over 3.6MB free, which is 128 to 232 times as much as I have now. (My Forth kernel is in ROM now though.) When I started using PC-boad CAD, it was on PCs with only 1MB of RAM, and I did some very complex boards with that, up to 500 parts and 12 layers, with no disc-swapping going on. I definitely won't be doing any CAD with the workbench computer, but I would like to eventually run a full-featured macro assembler for complete '816 applications; and the source code, list code, and object code together would fit in that amount of memory just fine. There's definitely more than enough memory there for manipulating very large arrays of data. If it weren't enough for streaming data of some kind, the external multi-megabytes, even gigabytes, of serial flash is available. I don't expect to be doing any graphics except oscilloscope and other test equipment functions. This is, after all, a workbench computer, not a gaming or web-surfing computer.

I do however keep toying with the idea of using one or two dual-port memories also, one being specifically for oscilloscope graphics, where I can put markers, text, etc. on an analog oscilloscope in raster graphics using a shift register to feed the data to the Z input for beam brightness and use the normal two inputs in X-Y mode for scanning like a TV, feeding them with D/A converters off the counters which are clocked by the shift-register clock. That and printing graphs on the printer are the only graphics I've ever done. The dual-port memories would require more address-decoding logic though, meaning we're back to programmable logic.

Quote:
Why wouldn't you want to use a PLD to produce a more robust decoding? Just curious.

I should look around for programmable logic software and a device programmer. I guess the main thing keeping me away is that I don't think I would use it enough to justify the cost in dollars and the time to learn to use it. [Edit, 2014: 5V programmable logic seems to be going away.] I also want something that's supported in Linux, or even something old-fashioned that runs under DOS. I won't use Windows again even so save my job. I'm through with it. It's not worth my health. When I was still using Windows, I was angry with the computer all the time. Then I met Linux, and more than 90% of my computer problems evaporated.

Speaking of DOS, I'm setting up another computer to try FreeDOS or DrDOS, both of which are multitasking and apparently much richer than DOS 6.22 was. I really know virtually nothing about them yet. I need to make sure I can get the DOS/ANSI [Edit: that should say IBM437] graphics character set with hi-res monitor support though, at least 132 columns like my other DOS machine, if not 200 columns, instead of the old 80 columns with the huge blocky letters most people think of when they think of DOS. The video card always used to be separate and came with driver software. Now the video is always on the main board.

_________________
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  
BillO
 Post subject:
PostPosted: Fri Dec 11, 2009 12:40 am 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
GARTHWILSON wrote:
Quote:
... There have been 2Mx8's for several years in 3V, but I think there are still too many things I want the computer to interface to in 5V, so I think I'll stay with 5V. ...


I've run 62LV1603's at 4.3v in otherwise 5v circuits with no trouble. I wouldn't use them in a comercial product due to liability concerns, but like I've said, I've not experienced any trouble.

_________________
Bill
Top
 Profile  
Reply with quote  
BigEd
 Post subject: Re: I/O not in bank 0
PostPosted: Fri Dec 11, 2009 10:47 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
GARTHWILSON wrote:
... and the reset vector and boostrap loader get pre-loaded into RAM before the processor is released for start-up.


I'm interested in how you're doing the bootstrap, especially if you're avoiding programmable logic. Please tell!
Top
 Profile  
Reply with quote  
fachat
 Post subject:
PostPosted: Fri Dec 11, 2009 3:18 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany
GARTHWILSON wrote:
Quote:
Why wouldn't you want to use a PLD to produce a more robust decoding? Just curious.

I should look around for programmable logic software and a device programmer. I guess the main thing keeping me away is that I don't think I would use it enough to justify the cost in dollars and the time to learn to use it.


I was shying away from this for a long time too, but finally decided to build me the Galblast programmer. It's relatively cheap.

Quote:
I also want something that's supported in Linux, or even something old-fashioned that runs under DOS.


I'm not sure though if Galblast is supported under Linux though, I use a small windows program that comes with it...

André
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Fri Dec 11, 2009 7:24 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
I'm interested in how you're doing the bootstrap, especially if you're avoiding programmable logic. Please tell!

I think I'll just put a 40-pin PIC on the bus to load the RAM while it holds the processor in reset. I may have it read the bootstrap loader program or even an OS out of a serial EEPROM which can quickly be changed and reprogrammed with my current workbench computer. I use this same workbench computer to program PICs too. [Edit, 12½ years later: I show what I did at viewtopic.php?p=91876#p91876 and on the front page of my site, linked below.]

_________________
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  
BigEd
 Post subject:
PostPosted: Fri Dec 11, 2009 9:03 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
GARTHWILSON wrote:
I think I'll just put a 40-pin PIC on the bus to load the RAM while it holds the processor in reset.

Ah, thanks. I'm not experienced in the way of the PIC, but that sounds like a good idea. Probably easier to program a PIC than to code up a state machine in a CPLD, and if you get a free interface to mass storage that's even better.
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Fri Dec 11, 2009 9:26 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
Probably easier to program a PIC than to code up a state machine in a CPLD, and if you get a free interface to mass storage that's even better.

especially since I've already brought several products to market that use PIC16's but can't claim any experience to speak of with programmable logic. I've done the code to bit-bang I²C on PICs too, for ones that don't have an I²C port, for the EEPROM, so it's almost a copy-and-paste for the software.

_________________
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  
8BIT
 Post subject:
PostPosted: Sat Dec 12, 2009 1:06 am 
Online
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
8BIT wrote:
... I have not tested the throughput yet, but I will soon.


Here are my somewhat-quick test results.

I transferred a 391,808 byte file using my CF-SPI storage and an RS-232 connection.

Code:
                  RS-232 (115200 baud)          CF-SPI

Bank 0 IO           98 seconds              16 seconds 

Bank 8 IO           98 seconds              18 seconds


Clearly, the CPU was waiting for the RS-232 data to arrive, even at 115,200 BAUD.

The SPI transfer suffered a little, but not too much. The SPI clock speed is about 3.5MHz so most likely, there was some waiting time for the CPU also.

I find the results acceptable for my application.

Daryl
Top
 Profile  
Reply with quote  
kc5tja
 Post subject: Re: I/O not in bank 0
PostPosted: Sat Dec 12, 2009 5:14 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
BigEd wrote:
I'm interested in how you're doing the bootstrap, especially if you're avoiding programmable logic. Please tell!


My Kestrel 1p3 system bootstraps entirely from RAM. See http://www.falvotech.com/content/kestrel/1p3/

It places I/O entirely in the first 32K of address space, and RAM in the 2nd 32K. No ROM. Bootstraps from a program downloaded into RAM using 74ACT595 shift registers, driven from a PC parallel port.
Top
 Profile  
Reply with quote  
BigEd
 Post subject:
PostPosted: Sat Dec 12, 2009 6:02 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Nice - i2c is another possibility, depending on what is most convenient. Having the BE input is valuable here. In my case, I hope to have a nearby CPLD to do the bootstrapping.

Funny, I've been thinking about whether Garth could keep his I/O in Bank 0 by choosing to map all his RAM only into the top half of every bank. It seems natural to place RAM at the top of the bank, to hold the vectors, and easy enough to locate Direct Page and the Stack up there, so I/O can happily live near the bottom.

But, the decoding would be slightly harder, the memory would be non-contiguous, each bank is only half-populated - and you've shown that there's barely a speed penalty to using long absolute addressing.

So, hardly worth mentioning!
Top
 Profile  
Reply with quote  
BigDumbDinosaur
 Post subject:
PostPosted: Tue Dec 15, 2009 1:28 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
Cypress is introducing a SRAM chip that's 4Mx8, but it's in BGA, not even SOJ or SOIC, and I don't know that I would ever be able to mount it by hand. If you know a way to do it, I'd like to hear it.

I've yet to see a satisfactory method of mounting BGA silicon by hand. I have a hard enough time with SOJ, etc.

Quote:
I was pleased to find out that that much bus loading (from 8 SRAMs) won't have nearly the effect on speed as I had thought. Still, I don't think I want to put 16 or 24 SRAM chips on the bus. I'll stop at 8.

Just about all of those SRAMs go into a very low power state when not selected. That does a lot toward keeping bus loading to an acceptable level.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 26 posts ]  Go to page 1, 2  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 39 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.