6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:57 am

All times are UTC




Post new topic Reply to topic  [ 430 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 29  Next
Author Message
PostPosted: Fri Jan 25, 2019 9:52 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
Welcome, backspace119! I'm a bit late to this party. You don't lack for ambition, and I commend you and will follow with interest... but I would echo advice to first build something simple: the minimal viable prototype, if you like. Build one to throw away. You'll learn a lot from that, and you can keep yourself from the distractions of adding features or chasing performance - you really want to start by making something which works! Modular is a related approach, but you can lose time and momentum figuring out how to support all the ideas you have, but haven't yet implemented.

One small comment, though, you mention wanting solid state storage, and lots of RAM, and lots of ROM. I think you don't need all three. Solid state storage is an excellent fit for retrocomputing, so that's a great idea, and a memory map full of RAM is also very liberating, compared to many historical machines. But you don't need much more ROM than it takes to load a binary from the solid state: it needn't even be smart enough to read a filesystem. (You may learn a lot even from this exercise, unless you happen already to have a good understanding of bootstrapping.)

I'd also, to some extent, echo the comments that a high resolution display is slightly at odds with a low performance CPU: unless you don't care too much about screen refresh, or you have a sprite engine or tile-based display or similar. I hope we all know that gameplay trumps everything else, if games are your target application. "Pac-Man's screen resolution is 224 x 288, so this gives us a total board size of 28 x 36 tiles." Space invaders was monochrome, 224×256 resolution. Tetris runs nicely on the NES at 256 x 240.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 9:56 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
GARTHWILSON wrote:
Daryl's 65SPI IC shifts a byte in and one out (SPI goes both directions simultaneously) in 16 clocks. You'll probably need that much time just to handle each byte during the process anyway; so it wouldn't be slowing you down. He is re-working the design for a newer CPLD since the old one became unavailable. I still have several here I could let go of. The 6522 has a synchronous serial port that's just as fast, although not bidirectional. A few people have used it for one of the SPI modes. I'd have to sharpen my pencil to see what tricks (if any) there might be to using it for SPI.

You read my mind, I was just trying to find a source for the chips like this, although I saw the SPI65b which seemed interesting as well, but I would be interested in chips to get me going on SPI with something that's simple and clean (I can bit bang if necessary, but I'd prefer to offload it from the CPU)

GARTHWILSON wrote:
The monochrome graphics LCD I've used, and another I plan to use, take a command to tell which dot row and column to start with in its internal memory. In this one, it wraps IIRC, so you would have to re-draw just the one row or column that wrapped around to the other side or end. I know I've seen other ones though that have an internal memory that's larger than the screen, so there's a certain amount of panning you can do without re-drawing anything.

this is interesting, and I've been revisiting the displays section, with a text display in mind for the original build (I'd like to do one big enough to run a BASIC interpreter without killing myself moving lines up and down on a 2 row screen)

GARTHWILSON wrote:
Yes, just change the bytes you want to, and take advantage of the rest already being what you want.

This is kind of what I wanted to do with the original "like a GIF" idea, but as was pointed out earlier, there's a SRAM IC that does composite video out, and small displays compatible with composite, so when I get to color video, I'll probably take that route, to take the heavy lifting off the 6502

GARTHWILSON wrote:
You can often get free dual-trace, triggered CRT oscilloscopes that businesses or schools are getting rid of, in the range of 20-100MHz. Do yourself a favor and get a decent scope. One of these will be way better than most of the cheap new digital ones like the worthless DSO Nano you hook to your computer, and certainly better than the scope from the 1950's. Just be sure to get a decent pair of 10x probes with it, and take care of them. Good probes are not cheap. There's a lot more there than meets the eye. (The 6502 primer's section on basic workbench equipment discusses this.)

Ya, the 1950s one is neat to use to look at audio, and watch the vacuum tubs work, but not much else, it's also a huge fire hazard because it's a caseless design with a ratsnest underneath instead of a board

GARTHWILSON wrote:
You're welcome. It was written to answer a lot of questions and problems that kept coming up over and over in the early years of the forum. It does get frequent small updates. The whole site probably has a thousand links, and I definitely can't check them all every week; so if you find that one has gone dead, please let me know.

I actually did find some dead links, I'll try and go through and document them for you soon, a bit busy at work atm though

GARTHWILSON wrote:
It's mostly unrelated. If anything, a lower voltage may cause less trouble, because parts are the fastest at their maximum voltage, producing faster edge rates that are more likely to cause ringing and double triggering, and also responding more quickly to it and being less forgiving.

I suppose it will mostly be based on what my critical ICs run at, so I'm not having to level shift between them and the CPU, I'd like to have the option to clock faster in the future though, in case my board is capable

GARTHWILSON wrote:
There are of course thru-hole sockets for PLCCs. Remember also that if you need additional parts or connections on the other side from a DIP, you can forgo the holes and just put pads down on the board to solder the DIP to, holding it on with solder fillets. That should be fairly easy to unsolder too, using solder wick.


As far as PLCCs go, and other programmable chips, I've never used them, and I'm not sure how to use them, I'm willing to learn though, as it seems a lot of ICs are not really made with the 6502 in mind, so I may need to implement some custom functionality. As far as the connections go, I'd prefer to have sockets and cleanly solder everything if possible, although I'm not sure how long a trace length is "too long" for different clocks

This picture shows a board I made up for 2 IO expanders, (I set up the addressing wrong on it) it is 2 sided, and you can see some of the traces on the top, this I generally how I like to set it up, except with sockets (this board was an early test)
Attachment:
pcb_with_chips.jpg
pcb_with_chips.jpg [ 2.89 MiB | Viewed 791 times ]


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 10:03 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
Chromatix wrote:
On 5V vs 3.3V:

Generally CMOS logic runs faster at higher voltages, including the currently-produced WDC 6502 and 65816, and the 74-series logic chips to go with them. WDC specifies their CPUs to 14MHz at 5V, but only 8MHz at 3.3V. System designers, however, think less in terms of MHz and more in terms of nanoseconds; fewer nanoseconds elapse before signals become valid at the higher voltages.

Some chips and peripheral devices, however, are not 5V-tolerant - including the Raspberry Pi - and are likely to "let the magic smoke out" if even briefly subjected to 5V signals. Conversely, some devices are designed for 5V only and won't work reliably at 3.3V (though some do actually still work, even though it's out of official spec). To bridge the gap, you will need to use a level shifting interface. Not a complete disaster, but a complication. Read your datasheets for things like SRAM chips and display modules with that in mind.

On a related note, avoid 74LS series logic in current designs, and note also that 74HC is less than optimal these days (though it's cheap and is fine for slow logic). Prefer 74AHC where available, or 74AC if the specific chip you want isn't in 74AHC. The 74AHCT family can be used to correctly interpret TTL (as opposed to CMOS) signals which don't go to the positive rail quickly enough, such as the output of 74LS series logic.


I did some mental arithmetic based on what I remember of the BBC Micro's video system. This is capable of producing a PAL-compatible 640x256x1b 50Hz signal from a 16MHz dot clock (Mode 0), by reading 8 pixels worth of data into the Video ULA during the Phi1 phase of the 2MHz 6502 cycle, during which the CPU doesn't "see" the bus. (The ULA was an early, mask-programmed version of what we would now call a PLD.) This offers a useful baseline for video timings, from which we can extrapolate. Many other classic micros used an odd-looking CPU frequency, because the same oscillator was used to drive the CPU and the NTSC or PAL colourburst carrier; the BBC Micro separated these concerns.

Keeping the same 16MHz dot clock and assuming 8-pixel-square characters, you could implement a "text and attribute" 80x32 mode in 5KB, which is relatively affordable. This would require fetching one byte full of character data and another byte full of colour data (4 bits each of foreground and background colour index) per 8 pixels, which you could easily squeeze into the Phi1 phase of a 4MHz CPU, or with a bit more difficulty into an 8MHz cycle (a 55ns SRAM should just about be able to keep up, if you have fast glue logic). You'd need to buffer these results so that they were presented to the character ROM and the CLUT synchronously with the leading edge of the relevant character cell. The CLUT would be a small RAM with 4-bit address and as many bits as you like of width, directly driving RGB DACs; you could update it during any blanking interval. Put the output of the character ROM in a shift register, clock that at 16MHz, and use each shifted bit to switch which half of the colour attribute is presented to the CLUT.

You can then add flexibility in the system by offering per-scanline programmable display address, character-ROM row number, pixel shift-register divider, scanout delay and length. Your text is now capable of being moved with pixel granularity, scaled up both vertically and horizontally, or simply skipped to free up a bit more RAM. If your character ROM can be put in a pass-through mode, you can go the other way and provide unique pixel data in each scanline, giving you a H/V-scrollable bitmap graphics mode with some colour capability - but consuming as much as 40KB RAM at full size and resolution.

Food for thought…


This is very interesting, I'd seen some of the clever stuff they used to do with the NES/Atari 2600 and similar, and I think some of what you're saying touches on it, I'll always opt for clever usage of available resources over slapping an over powered chip to bludgeon the problem to death.

As was mentioned earlier, there is an SRAM IC that does composite video generation, and some small composite compatible displays out there, so I'm hoping to use that combination when I make it to color video


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 10:05 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
DerTrueForce wrote:
BitWise mentioned the original Gameduino, which has VGA output on it. However, there is also the Gameduino 2/3, which come with a built-in display. It is interfaced over SPI, though, which may complicate things.


As much as I like the look of these boards, I think I'm going to make another goal of trying to use as few prebuilt PCBs as possible, and also, the built in display is a great way around using VGA though, so I may look into this as a last resort.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 10:11 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
BigEd wrote:
Welcome, backspace119! I'm a bit late to this party. You don't lack for ambition, and I commend you and will follow with interest... but I would echo advice to first build something simple: the minimal viable prototype, if you like. Build one to throw away. You'll learn a lot from that, and you can keep yourself from the distractions of adding features or chasing performance - you really want to start by making something which works! Modular is a related approach, but you can lose time and momentum figuring out how to support all the ideas you have, but haven't yet implemented.

One small comment, though, you mention wanting solid state storage, and lots of RAM, and lots of ROM. I think you don't need all three. Solid state storage is an excellent fit for retrocomputing, so that's a great idea, and a memory map full of RAM is also very liberating, compared to many historical machines. But you don't need much more ROM than it takes to load a binary from the solid state: it needn't even be smart enough to read a filesystem. (You may learn a lot even from this exercise, unless you happen already to have a good understanding of bootstrapping.)

I'd also, to some extent, echo the comments that a high resolution display is slightly at odds with a low performance CPU: unless you don't care too much about screen refresh, or you have a sprite engine or tile-based display or similar. I hope we all know that gameplay trumps everything else, if games are your target application. "Pac-Man's screen resolution is 224 x 288, so this gives us a total board size of 28 x 36 tiles." Space invaders was monochrome, 224×256 resolution. Tetris runs nicely on the NES at 256 x 240.


I hadn't thought about this at all, but this makes perfect sense. The one complaint I have is, I'd like to have a bit of ROM to ease programming of games, by way of "drivers" and a small "kernal" (boot code or init code), so maybe I can squeeze in 1k eeprom at the very end of the address bus? or maybe this is unecessary and I can put all this in flash. The only reason I'm thinking eeprom is to save memory and program space for common actions (talking to peripherals, drawing to the display, etc) although I suppose I'd have to at least have pointers in code to the ROM addresses where these small bits of code were stored.

Does this make any sense or am I missing the point of using flash only?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 10:16 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
It certainly makes sense to write something of a kernal and some graphics library, but you might as well load it from solid state into RAM - I think. Maybe the thing to optimise is the ease of development and update. With almost all software on an SDCard, you just have to whip it out of your micro, slot it into your PC, and copy your latest code. Updating any kind of ROM is probably going to be more involved. But don't take my word for it - do a bit of reading and a bit of sketching of possible solutions.

Certainly in the few bringups I've been involved with, getting to the point of booting to a monitor program with a hex loader has been a major milestone, because it's then easy to paste hex dumps over a serial connection to load software under development. (I've generally worked with systems that have a serial port.)


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 10:21 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
BigEd wrote:
It certainly makes sense to write something of a kernal and some graphics library, but you might as well load it from solid state into RAM - I think. Maybe the thing to optimise is the ease of development and update. With almost all software on an SDCard, you just have to whip it out of your micro, slot it into your PC, and copy your latest code. Updating any kind of ROM is probably going to be more involved. But don't take my word for it - do a bit of reading and a bit of sketching of possible solutions.

Certainly in the few bringups I've been involved with, getting to the point of booting to a monitor program with a hex loader has been a major milestone, because it's then easy to paste hex dumps over a serial connection to load software under development. (I've generally worked with systems that have a serial port.)


I guess you're right, because the ROM space could be expanded to more RAM, and if we tried to have the RAM and ROM we'd need to page to the rom through another device's io, making our libraries slow because of increased propogation time.

Would this allow me to have 64k ram and then use io on another device to (albeit slowly) load binary from flash?

Also, I'd like a hex terminal to run underneath some of this, if at all possible, for easier live debugging over a serial interface, and also possibly for multi-game selectability (roms placed 64kb apart on flash and paging used to load a particular one) ofc, this is an explosion in scope, and would be after I build my first machine

EDIT: I suppose I need to remember I need some addresses for IO, so 64k ram is not possible without putting some behind additional IO, so maybe 63k RAM and 1k io addresses?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 11:08 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
It's easy to mark out a single 256-byte page, directly between the RAM and ROM spaces, for I/O. All you need is an 8-bit magnitude comparator, which outputs less-than (RAM), more-than (ROM) and equal (I/O) signals. You can then subdivide that page further into 16x 16-byte chunks using a 4-to-16 decoder, whose enable pin is tied to the equal output of the comparator.

If you think RAM will get tight, you could take a page from my book and provide paged RAM banks. In the design I'm theorising at the moment, there are sixteen 1K areas between a 16KB ROM zone and a 32KB flat RAM zone, with an 8-bit page register (just an 8-bit latch) associated with each. The page register is connected to the high address lines of a 256KB SRAM chip, with the low ten bits coming from the CPU. Not only does this give some good RAM expansion opportunities, but it can be used as a vehicle for accelerated multiplication and division, by filling that RAM with lookup tables. Since what I'm trying to build is a high-precision, high-utility calculator, that sort of good arithmetic performance might turn out to be useful.

You could also use those banked areas to attach large EEPROMs for reasonably fast non-volatile storage. I think 4MB chips are readily available with a convenient interface, significantly larger in capacity than most classic micros' floppy drives, yet faster and easier to work with. Put routines to flash files from the serial port into those EEPROMs in your main ROM; I advise including a checksum test. With careful mechanical design, you could turn those into pluggable cartridges.

Or you could make life slightly easier by using a 65816 instead of a 65c02. That gives you a 24-bit address space, even if you never leave emulation mode, because the new opcodes with "long addressing" still work. You'll still need a small boot ROM at the top of the 64KB space, just to handle bootstrap, but you can map something much larger into high memory and just not bother with paging.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 11:13 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
backspace119 wrote:
GARTHWILSON wrote:
There are of course thru-hole sockets for PLCCs. Remember also that if you need additional parts or connections on the other side from a DIP, you can forgo the holes and just put pads down on the board to solder the DIP to, holding it on with solder fillets. That should be fairly easy to unsolder too, using solder wick.

As far as PLCCs go, and other programmable chips, I've never used them, and I'm not sure how to use them, I'm willing to learn though, as it seems a lot of ICs are not really made with the 6502 in mind, so I may need to implement some custom functionality.

I think you were thinking of CPLDs (complex programmable logic devices). PLCC stands for "plastic leaded chip carrier," a type of IC package that has pins J-leaded around all four sides. The 65c02, '22, '51, '134, and '265 are available in PLCCs.

Image

_________________
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: Fri Jan 25, 2019 11:21 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
GARTHWILSON wrote:
backspace119 wrote:
GARTHWILSON wrote:
There are of course thru-hole sockets for PLCCs. Remember also that if you need additional parts or connections on the other side from a DIP, you can forgo the holes and just put pads down on the board to solder the DIP to, holding it on with solder fillets. That should be fairly easy to unsolder too, using solder wick.

As far as PLCCs go, and other programmable chips, I've never used them, and I'm not sure how to use them, I'm willing to learn though, as it seems a lot of ICs are not really made with the 6502 in mind, so I may need to implement some custom functionality.

I think you were thinking of CPLDs (complex programmable logic devices). PLCC stands for "plastic leaded chip carrier," a type of IC package that has pins J-leaded around all four sides. The 65c02, '22, '51, '134, and '265 are available in PLCCs.

Image


Oh, yes I was thinking of CPLDs, my bad.

I think that I'm going to work on a block diagram tonight to flesh out what I want v1 to be (trying to keep it simple) then a memory map, then a simple paper schematic, then maybe a kicad schematic.

About how much are you selling those SPI chips for? any other neat chips you're selling?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 11:24 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
Chromatix wrote:
It's easy to mark out a single 256-byte page, directly between the RAM and ROM spaces, for I/O. All you need is an 8-bit magnitude comparator, which outputs less-than (RAM), more-than (ROM) and equal (I/O) signals. You can then subdivide that page further into 16x 16-byte chunks using a 4-to-16 decoder, whose enable pin is tied to the equal output of the comparator.

If you think RAM will get tight, you could take a page from my book and provide paged RAM banks. In the design I'm theorising at the moment, there are sixteen 1K areas between a 16KB ROM zone and a 32KB flat RAM zone, with an 8-bit page register (just an 8-bit latch) associated with each. The page register is connected to the high address lines of a 256KB SRAM chip, with the low ten bits coming from the CPU. Not only does this give some good RAM expansion opportunities, but it can be used as a vehicle for accelerated multiplication and division, by filling that RAM with lookup tables. Since what I'm trying to build is a high-precision, high-utility calculator, that sort of good arithmetic performance might turn out to be useful.

You could also use those banked areas to attach large EEPROMs for reasonably fast non-volatile storage. I think 4MB chips are readily available with a convenient interface, significantly larger in capacity than most classic micros' floppy drives, yet faster and easier to work with. Put routines to flash files from the serial port into those EEPROMs in your main ROM; I advise including a checksum test. With careful mechanical design, you could turn those into pluggable cartridges.

Or you could make life slightly easier by using a 65816 instead of a 65c02. That gives you a 24-bit address space, even if you never leave emulation mode, because the new opcodes with "long addressing" still work. You'll still need a small boot ROM at the top of the 64KB space, just to handle bootstrap, but you can map something much larger into high memory and just not bother with paging.


I've heavily considered using the '816, although there are 2 issues. 1: I've heard something about the address lines being multiplexed on the high 8 bits to get the 24 bit bus while remaining pin compatible with the 6502, I'm not exactly sure how to work with this. 2: iirc the 816 is capable of higher speeds, which I'm not sure I'd be able to give it, not really an issue, just worried I wouldn't get everything I could out of it

There's a small non issue, that I'd enjoy the challenge of completing this with just a 6502, but I am open to using the 816

As far as mapping all of that, is your ram access any slower because it's paged like it is? Do you think the eeprom is actually worthwhile instead of storing whole binaries in flash and then loading to RAM?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 25, 2019 11:42 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Flash is just a type of EEPROM. The difference, I think, is in the erase-block size, the tradeoff being flexibility versus density. Many EEPROMs are slower than SRAM, so you may find you need to insert a wait-state (via RDY) when accessing them. There are circuits to do that in the primer.

The extra address bits of the '816 are multiplexed on the *data* bus pins. You capture them using an 8-bit transparent latch, opened by the combination of Phi2 low and RDY high. This has very little effect on timings for actual data on the bus.

The paging scheme I outlined has virtually no implications for performance. Address decoding to select the correct device is something you need to do anyway. You could connect the output of a page register directly to the SRAM, completely eliminating any wait for the latch's output enable to propagate. Or you could make several pages visible simultaneously by mapping the same SRAM into multiple 1KB windows, each with their own page register. Modern 74AHC logic is fast enough to do that without really worrying about it.

There are some differences in the '816's control signals versus the 6502. I rather like the provision of VDA and VPA, so you can tell when the CPU is performing an "internal operation" and not actually accessing the bus.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 26, 2019 3:03 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
backspace119 wrote:
About how much are you selling those SPI chips for?

I paid $4.25 each plus shipping. How's that? (I lose the amount of the original shipping, but it's not enough for me to be concerned about.) I should have put them on the front page of my site, but I never thought of it. I think I have about a half dozen.

Quote:
any other neat chips you're selling?

The only actual ICs I supply separately are the pairs of 1MB EPROMs with the large look-up tables. Otherwise just the little memory modules shown on the front page of my site, one for 4Mx8 of 10ns 5V SRAM, and then the tiny boards and connectors for SPI-10 serial flash memory. I have not sold any of the latter, probably because I never did come up with a price and promote them, and now I'd have to look up how much the connectors cost me since I can't remember. The price of the bare boards themselves would probably be dwarfed by the postage if someone only bought one or two, LOL. Last year I did not get any real 65xx activity done, as my work had me busier than usual. I hope to get with the program again this year and add another module or two to facilitate the construction of hobby computers, and maybe another major feature to my website too. This is all to promote the interest; so although I have a legitimate business (and I have to collect sales tax from California customers), it does not need to be profitable to keep going indefinitely.

As for the 65816: A16-A23 are multiplexed on the data bus; but if a 64K address map is enough, you don't have to latch, decode, or use those high eight bits. You still get a ton of benefits from the 816's added instructions and addressing modes, and the fact that you can put A in 16-bit mode, and you can put the index registers in 16-bit mode, the stack pointer is 16-bit also, the "zero page" is called "direct page" because you can move it around (and it's not required to start on a page boundary), and probably a lot of other benefits I'll think of as soon as I click "Submit" here. It really opens up a bigger world. If you're timid (which is fine), you could lay out a board that accommodates either the '02 or the '816 by using jumpers. The '816 powers up in '02-emulation mode though (albeit with a lot of extra instructions available). After you get your feet wet, you'll probably want to put it in native mode in the reset routine and never touch that mode bit again.

_________________
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: Sat Jan 26, 2019 3:42 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
GARTHWILSON wrote:
backspace119 wrote:
About how much are you selling those SPI chips for?

I paid $4.25 each plus shipping. How's that? (I lose the amount of the original shipping, but it's not enough for me to be concerned about.) I should have put them on the front page of my site, but I never thought of it. I think I have about a half dozen.

Quote:
any other neat chips you're selling?

The only actual ICs I supply separately are the pairs of 1MB EPROMs with the large look-up tables. Otherwise just the little memory modules shown on the front page of my site, one for 4Mx8 of 10ns 5V SRAM, and then the tiny boards and connectors for SPI-10 serial flash memory. I have not sold any of the latter, probably because I never did come up with a price and promote them, and now I'd have to look up how much the connectors cost me since I can't remember. The price of the bare boards themselves would probably be dwarfed by the postage if someone only bought one or two, LOL. Last year I did not get any real 65xx activity done, as my work had me busier than usual. I hope to get with the program again this year and add another module or two to facilitate the construction of hobby computers, and maybe another major feature to my website too. This is all to promote the interest; so although I have a legitimate business (and I have to collect sales tax from California customers), it does not need to be profitable to keep going indefinitely.

As for the 65816: A16-A23 are multiplexed on the data bus; but if a 64K address map is enough, you don't have to latch, decode, or use those high eight bits. You still get a ton of benefits from the 816's added instructions and addressing modes, and the fact that you can put A in 16-bit mode, and you can put the index registers in 16-bit mode, the stack pointer is 16-bit also, the "zero page" is called "direct page" because you can move it around (and it's not required to start on a page boundary), and probably a lot of other benefits I'll think of as soon as I click "Submit" here. It really opens up a bigger world. If you're timid (which is fine), you could lay out a board that accommodates either the '02 or the '816 by using jumpers. The '816 powers up in '02-emulation mode though (albeit with a lot of extra instructions available). After you get your feet wet, you'll probably want to put it in native mode in the reset routine and never touch that mode bit again.


I'll gladly take one or two off your hands at that price, is there a reference schematic on the primer? I don't remember. I can work out the details with you in a pm.I also think you're right about the 65816, if I want to try and achieve this only using 6502 capabilities I still can, using its emulation mode, and if I can't do it, then I won't have wasted $7 and shipping on a chip I would need to replace (and possibly the board too, since it may not be compatible with the 65816 in native mode)

I've been trying to chug through a block diagram to try and lay out exactly how I want this to go, after what Chromatix said about paging and setting up devices on the address bus, I think I may attempt to get a little more on it, like RAM + EEPROM + FLASH + some expandability for things like sound and possibly video.

To make sure I'm on the right track here, I'm thinking I put the flash behind...well, actually, since I can get that SPI chip from you I can put flash on the SPI bus from that chip, which...I think the SPI chip should go behind the 6522? and then I could possibly get some sort of serial connection out of the 6551 for connecting to a computer for debugging (RS-232 or similar), put EEPROM behind a 6522 and then SRAM mapped as Chromatix suggested...something I just realized is, I've worked with 25017 chips and 25s17 chips before (first is i2c, second is SPI) which are IO expanders with 8 I/O on port A and port B with 2 interrupt I/O (one for A and one for B) are these chips at all similar in function to the 6522? if so, can I use them for anything? Also, as Chromatix suggested, I'm thinking of doing 18 bit SRAM, with first 10 bits from addr bus and an 8 bit register fed by I suppose a 6522.

If you can't tell from the above text, I am a bit timid about this, but only because I want a working computer, not a pile of smoking chips. I'm still sort of figuring out the setup of chips so I can make a block diagram to make a schematic out of.

EDIT: I think what I'm going to start with is a boolean/binary logic diagram of address decoding, since I'm very comfortable with that, and make a few assumptions about general chip function just to get it going, this will also allow me to more easily set up a memory map


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 26, 2019 5:32 am 
Offline
User avatar

Joined: Mon May 12, 2014 6:18 pm
Posts: 365
Regarding video generation, one idea I have thought of (for your second or third build) would be copying RAM with a CPLD. I have not tried doing it yet but it is simple in theory. You would have one RAM chip for the background and draw this (slowly) with the 6502 then trigger the CPLD to copy the background to another chip. All the CPLD has to do is output the value of a 16 bit timer to drive the address lines of both ram chips and generate read and write signals. The 6502 goes about its business while the counter counts down copying data. Next, the 6502 draws sprites and stuff to one of the chips then triggers the CPLD again to copy the complete image to the color LCD. While this is happening, the 6502 is free to do other stuff like game logic. When that is done, repeat the process by copying the background to the second chip again and drawing the next frame. You could also add more of these buffers to speed things up since you can copy the background to more than one chip at once.


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

All times are UTC


Who is online

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