New Guy - With Project!

[BitWise]

Dimitri wrote:

Well to be fair I probably only need 10 digits of precision accurately. After all we have significant figures to deal with so 10 should be plenty. Floating point probably is not necessary. The co-processor is a solution in my head to save cycles on the 8-bit uC so it doesn't need to worry about doing any math. Concentrating on running the OS-like software and the interpreter.

A 32-bit floating point number (with a 24-bit mantissa) is only accurate to around 7 decimal places and error propagation can easily reduce this to 5 or 6 places.

You'd be better off developing BCD arithmetic routines - thats how many calculators work internally.

http://www.diycalculator.com/

[Dimitri]

kc5tja wrote:

On the other hand, I've had to maintain classes with single methods exceeding two thousand lines of code. That's always a lot of fun. :-/

I've used functions with 500 lines of code in one, just cause I wanted a universal call up for graphics in a simple 2D game I made once.

Really, look how I want to make module based this project and imagine that as how I program.

Dimitri

[Dimitri]

Update, on Garth's suggestion that it be a one board system, I downloaded the Vector layout template for their 4610 and started to draw components on it.

I have more or less acceptably fit everything on the board, making it a single board computer. However I will keep the STD like bus interface to allow future expansion if I so wish to do.

Without modularity, I don't see a device as a "desk computer" per say. So my "special" STD bus will probably still be used and I still included the chip on my board.

If I can get a to a scanner I will post my drawn layout so you can critize it as much as you wish.

Dimitri

[kc5tja]

Dmitri, just curious -- what clock speed are you planning on using for your computer? I don't recall reading that anywhere in this thread yet.

Thanks.

[Dimitri]

I was going to test it at running at 20Mhz. Never actually ran a AVR that fast before, due to not really needing to in a microcontroller based robot etc. I've ran them at around 8-10Mhz in the past.

The ATmega644PV is apparently able to run at 20MIPS at 20Mhz and its max frequency is 20Mhz. I figure if stability becomes a issue I can always lower the clock.

Dimitri

[8BIT]

I'm running my ATMega324P at 20MHz (rated speed) and it runs great, no hitches or glitches.

Daryl

[kc5tja]

OK, that should be fine then. I was just wondering because of the STD-bus.

I have often considered making my own "microprocessor" by implementing a virtual machine in an ATmega32 or some such, and just taking the 10:1 performance hit that emulation would bring. The chips are so cheap, and oscillators are so cheap, that a 1MHz to 2MHz external bus performance should be more than acceptable for the kinds of virtual machines you can implement so easily.

And, besides, if a TMS9900 can take a 12:1 performance hit (4:1 clock to bus cycle ratio, with most instructions taking two to three bus cycles), I think a 10:1 performance hit is more than acceptable.

[Dimitri]

Thanks Daryl,

That is really good to know. Your SBC project looks real interesting, keep up the good work!

Samuel,

Its a "STD" like bus, although implementing a real STD-80 is unnecessary as Garth says, cause its a expansion of normal CPU control/data lines, and I am running a microcontroller. It does give me Vector Electronics as a source for the components to build my own system, that is not made in China to boot.

I will probably build my own backplane board, just so I can make it 1" spacing between boards. I like using DIP sockets instead of soldering components, also makes it easy to pull them and reprogram them on the STK500. Plus I can test the circuit board with my multimeter without worrying about applying voltage to the wrong pin on a IC.

Once the SBC is working, and this project is "done" I want to implement a floppy drive storage unit, as well as a HDD unit on a single card. I do believe I still even have a 500MB HDD laying around. Failing the HDD from working I'll use compact flash since its the same ATA specification. And since the ATA specification has already been done on the AVR it shouldn't be too hard to integrate. The FDD will be the hardest. But I found that they still produce dedicated FDD controller chips, so atleast I don't have to develop a controller for it!

Dimitri

[kc5tja]

I just researched the STD-80 bus, just to refresh my memory, and along the way, discovered a bus I'd never heard of before: STEbus. This bus looks like a perfect fit for the 65816 architecture, and (at least) CMOS 6502 variants.

Correction: Looks like I have heard of it before, but I completely forgot about it: viewtopic.php?t=894&highlight=stebus

[GARTHWILSON]

Since you mentioned data buses on the STD connector, I should probably comment that several years ago I was planning on having a parallel expansion bus in addition to the synchronous serial ones I mentioned, but finally canned the parallel one because it was too much complexity with almost no benefit. You're free to do anything you want of course, but I speak from the experience of many scores of workbench-computer projects and ATE. I should probably also say that the custom boards we made for the ATE in the STD cage were STD in mechanical form only, and that the communication between them and the CPU was synchronous serial. Those were not on the bus itself. Most of the pins handled analog signals. Only the off-the-shelf boards we used were true STD bus with its parallel interface. So there was a smaller, perhaps 5"-long, STD-bus backplane for the STD-bus portion of the 19" card cage, with system power supplies to the right (behind the LCD and keypad), and custom, non-STD boards to the left.

[Dimitri]

Samuel,

Thank you, I will read more into the STE bus.

Garth,

That is good to know. Perhaps maybe I should just keep the "Address" lines and the SPI interface then, and tie any new cards into the SPI interface instead of using any parallel lines. I will however be forced to keep the address lines I believe, as a method I could select the SPI slave in use at any given time. What do you think?

Dimitri

[kc5tja]

Since you're driving your expansion bus with a microcontroller, and not with "the processor" itself, I don't see a problem with this.

I've made peripherals for parallel buses before, and they're not that difficult. I'm interested in hearing more about what difficulties Garth ran into with his projects.

Keep in mind that the GPIB is also a parallel bus, and it's considered a classic, both from an ease-of-understanding and ease-of-use perspective.

I can cite one source of complexity with using the STEbus though -- the DASTB and DATAK signaling, used to signal when a bus transaction starts and finishes, is very foreign to the 6502 processor, which uses a synchronous bus interface. Even so, the external logic needed to implement it is quite simple. You just need to remember to do it.

If you're driving the bus from a microcontroller, I see no need for concern, since DASTB and DATAK appear to implement your typical 4-phase asynchronous bus transaction protocol. (Without more complete information on the STE-bus, I cannot be certain. But if it implements the 68000-style asynchronous protocol, I know for a fact it's 4-phase.)

[GARTHWILSON]

Quote:

maybe I should just keep the "Address" lines and the SPI interface then, and tie any new cards into the SPI interface instead of using any parallel lines. I will however be forced to keep the address lines I believe, as a method I could select the SPI slave in use at any given time. What do you think?

I like to encourage the use of our 65SIB which does what you're talking about here, plus quite a bit more. If we all start building with it, we can do more sharing of designs and even hardware. I think Daryl already has an IDE controller on 65SIB to offer. I have an SPI graphic LCD that I'm putting on 65SIB. Each 65SIB device shifts the select lines over one position so there's no risk of duplicate addresses, and in fact the first device in line is automatically address 1, the next is address 2, etc.. You can of course have more than one 65SIB if you want.

Quote:

I've made peripherals for parallel buses before, and they're not that difficult. I'm interested in hearing more about what difficulties Garth ran into with his projects.

No particular difficulty, but with big projects, construction time becomes a big issue, and parallel buses require a lot more of it because of all the additional connections. I was planning to have the parallel expansion bus go through VIAs so it would not slow the processor down and so I could, if I wanted to, put old, slow parts on it, like a 1MHz Commodore video interface chip, or a Saronix RTC58321 real-time clock (which I think had a maximum speed of something like 100kHz). But especially with more and more great SPI and I²C parts on the market, I began to realize I probably wouldn't ever get enough use out of the parallel expanpansion bus to justify the extra work, board space, and extra parts.

[kc5tja]

Well, if it makes folks feel better about the choice between a serial or parallel interface system, let's examine the Commodore VIC-II bus bandwidth requirements.

Keep in mind the VIC-II has a 12-bit data bus, not an 8-bit bus. However, only the lower 8-bits are used for most bus transactions. It uses the top 4 bits only when fetching color data.

Every time the VIC-II chip addresses memory, it places a 14-bit address on the bus. In the worst case situation, it reads back a 12-bit number. It's capable of doing this 2.016 million times per second (with all sprites enabled and fetching badlines, it'll use both phase 1 and phase 2 of the clock).

14+12=26 bits, which fits inside a 32-bit quantity. Hence, per SPI rules of conduct, we need a 64MHz SPI interface to satisfy the VIC-II's insatiable hunger for graphics data under worst-case performance considerations.

If you're willing to sacrifice the hard octet requirements, you can get by with a 52MHz SPI bus.

With some optimization, however, you can drastically reduce the bandwidth requirements. Under ideal conditions, you can assert the VIC fetch address once, and just stream data back to the chip. This would enable a reduction of throughput down to a more reasonable 16MHz (8 bits times 2 bytes per microsecond).

And this is just for a video chip that generates 320x200, color-tiled graphics. Imagine something with more color resolution, more spatial resolution, or higher refresh rates.

For example, a 640x480, 60Hz, 16-bit color display (essentially the minimum expectation of anyone looking at a computer display these days) would require an SPI connection about 295MHz data rate.

Therefore, I think there's value in a parallel expansion system. You might not need 8 slots. Maybe only one, perhaps two would suffice.

[GARTHWILSON]

Quote:

Therefore, I think there's value in a parallel expansion system.

Would you really want it going off board though? Although I have virtually no knowledge of color graphics displays, I would think the driver circuitry would be something you would especially want on the CPU board if possible. If the VIC used the same memory as the processor, you would have to slow the processor waaaaaaay down for them to work together, right? But I'm not sure if I understand you to be saying that it has its own separate video-memory bus. That would definitely be parallel, regardless of how the processor talks to the VIC and maybe goes through the VIC to store data in the video RAM.

On my workbench computer, I do interface to the A/D and D/A converters in parallel, through a VIA, but they're not really on a parallel expansion bus. A write to the D/A is just a 4-clock STA to the VIA port, and a read from the A/D only requires lowering the VIA CA2 bit to select it, then reading the 8-bit port for data, then de-selecting again. Either can do sampling for frequencies way beyond the audio range with a 5MHz φ2 although if it's interrupt-driven, the jitter only lets you get 6-bit accuracy up to about 4kHz audio which has been plenty for my applications. Actually, with the trick using the WAIt instruction on the '816, you can eliminate the jitter though.