6502.org

Maybe I missed it, but I don't remember Dmitri talking about exposing the STD-bus so far off-board that it involves running ribbon cable half-way across a desk. A PCB card-edge connector would be sufficient.
The vast majority of computers have off-board display devices. Integrated chipsets are routinely disabled in favor of 3rd-party graphics cards manufactured by ATI or nVidia. Just about the only on-board video devices used today are those found in servers, and only for convenience's sake. Insofar as their capabilities, they're usually not much more sophisticated than the Amiga's display hardware (e.g., super-basic 2D acceleration on average).

And this is a good thing, because technologies advance regularly. That Matrox graphics card is awesome for AutoCAD and desktop publishing, but pathetic for arcade games. Conversely, that TV capture card (another extremely high-bandwidth device) has no on-board analog at all. And what happens if you want to expand your computer from one monitor to two, but you only have one on-board video source?
Surprise!! The VIC-I and VIC-II chips use the same RAM that the processor uses. VIC-I relies exclusively on phase-1 access, while the VIC-II uses phase-1 for most, but occasionally needs phase-2 access as well (usually for sprite and character-matrix access). Google for "VIC-II bad-lines" for more detail on the subject than I can provide here.

This is why I said that the C64's bus runs at 2.016MHz (and, in fact, any 65xx-bus will technically run at 2F, where F is the CPU's clock frequency. It has to, by definition, for no 65xx processor transfers data during phase 1!).
You misunderstood greatly, I'm afraid.

I'm saying the equivalent SPI interface for the C64's memory architecture must be at least 52MHz in order to maintain its timing relationship with the processor. I also said that if you optimize the interface (e.g., are no longer bus-timing-compatible with the VIC-II), you can shrink it down to 16MHz.

The VIC-II not only shares the bus with the processor, it dominates the CPU entirely and utterly. The VIC-II is what generates the CPU's clock. It's what controls the CPU's access to RAM. It's also what generates DRAM timing information. You want a free performance boost on the C64 and C128? Blank the screen. Want to run the CPU at 2MHz on the C128? You must blank the VIC-generated screen.
The Commodore 128 uses a VDC chip for its 80-column display and graphics. To do so, the 8502 accesses video RAM through the VDC chip. The performance is horrible compared to the VIC, because the CPU has to wait for the VDC to finish display refresh before it can let the CPU access through. Worse, instead of the VDC asserting the CPU's RDY line, the CPU has to soft-poll to see when it's ready. This is why most 80-column C128 programs also put the CPU in 2MHz mode (which eliminates the 40-column display too; see above) to make up for the loss in performance.

But let's not go there -- I never brought up the VDC, nor do I want to persue it.

My purpose is to demonstrate that a need for parallel interconnects exists. I used video generation because it's trivially understood. You have 320x200 pixels to display, and you need to do it 60 times per second. Even the simplest of assumptions (black and white only, no text modes, no sprites, etc) will demonstrate a rather substantial bandwidth requirement.

Another great example -- those HDMI connectors you see everywhere. Essentially, these are DVI connectors in a smaller form-factor. DVI transmits video information at gigabits per second speed, AND over multiple lanes concurrently. E.g., each color channel is a single serial link, but it's running six (two reds, two greens, and two blues) channels in parallel. You're free to do the math on that one.

As promised a scan. I was at my college on a Sunday!

http://i35.photobucket.com/albums/d178/ ... can001.jpg

Don't look at the crystal circuits though, don't ask me how but I managed to make them wrong twice. The top left hand corner method is the right way. Next time I should just look over my notebook instead of ASS-U-ME'ing that I remember.

Been thinking about making a change instead of the Microchip EEPROM just to use the Atmel equivalent. Due to the fact Atmel has interfacing guides and programming data available when using them with the AVR series.

Also looking in to finding a good frequency converter/counter for a expansion board to work like a "Dummy" Oscilloscope. The AVR does have limitations when using it in such a function (5Khz max, 1khz typical), have been looking for a solution that would atleast allow me to measure up to 10Mhz no such luck yet.

Dimitri

Hey Garth,

I've avoided the larger memory capacity chips because I have never soldered SOIC, is it that difficult? I have resoldered surface mount resistors and the like however.

I will have to look into it thank you.

Dimitri

Sounds like a plan Garth thanks!

However I think I am going to go with a 8Mb or 16Mb Flash chip. Just because I have told everyone I am building a computer with the capability from the 80s.

I don't think I will ever need that much code space. Considering its going to be programmed alot like a HP-41C. All the save data will be is a text document where when you save a LBL function the text document's name will be "XXXXX.txt" instead of "LBL XXXXX". Even at 4Mb of space I figure you could have more LBL commands into the memory then you'd remember what they were for originally by the time you use them again. Or atleast I'd probably forget by then.

That is until I get a hold of how to use Forth and compile a Forth Interpreter into the same AVR core. Probably in revision 2, as I am still just learning from reading online Forth.

Dimitri

The multimegabyte storage space is mostly for data, not programs.


Forth doesn't require much room, except that I do like to put lots of tables and diagrams, even timing charts for the devices I'm controlling, in my source code (since the program is always controlling some kind of hardware outside of the computer), sometimes explain why I did something one way and not another that may initially seem better, etc., so my source code is certainly bigger than minimalist code with little commenting would be.

BTW, "compile a Forth interpreter" is a bit inaccurate. Although the interpreter is indeed compiled (or assembled, if you start with assembly source and assembler), you can have a Forth system with no interpreter at all if the user is basically an appliance operator and receives a ready-made system that needs no command line or compilation ability. What the interpreter does is to take words in the command line or other input stream and look them up in the dictionary, then execute, compile, or assemble, as appropriate. Programs are compiled before running though. They do not get interpreted at run time.

Sorry for the disappearing act, busy with school, took some time today to open my notebook (yes paper notebooks still exist) as a break from studying integration of transcendental functions to look over my plan, thinking about looking into high pin count AVRs to limit the number of chips needed in ratio to I/O.

Garth,

What would you call a terminal like situation that would read a prewritten .txt file to run or a line by line entry in a terminal situation? No real compiling per say. That is how I think this would run since it will be very similar to HP41 programming for now. When I figure out Forth completely I'll reflash it at a later date with a minimal Forth terminal/compiler or keep the compiler separate as a additional feature.

None the less back to work see you all next week.

Dimitri

That does sound pretty much like just making the source code file the input stream in Forth, but you'd have to work out some kind of branching method for it since that's mostly only done when running compiled code. Forth's compiler itself is only a few lines though, not a separate big program. It's only 40 bytes in my '816 Forth. Strictly speaking, I suppose one could say , ("comma") is the compiler, which is only two bytes to call. Once each word is looked up in the dictionary to get its code field address, the difference between executing it and compiling it is whether EXECUTE or , gets used, each of which takes two bytes to call. Initially it may sound very limiting; but gradually you learn the meaning of "power through simplicity," ie, where you have very simple tools but virtually no limits how to use them, including as building blocks for more-complex tools.

The dictionary does seem to address what you're talking about. You probably wouldn't have to use Forth to implement it, but you might as well, just to avoid re-inventing wheels. Everything in Forth is a "word," whether it's a routine, a variable, a data structure, a constant, or anything else you want to invent. Even things that look like punctuation are words (for example, the , above). INTERPRET goes through the input stream (which is the text program you're talking about) and looks up each word in the dictionary to get an address of some code that will be meaningful to the computer. If the word is not in the dictionary, it tries to make sense of it as a number. If that works, it puts the number on the stack (like you're familiar with on the HP calculators), otherwise it gives an error message. Each dictionary entry, ie, each word in the vocabulary, in indirect-threaded code with headers (there are other ways to do it too, but I'll ignore them for now) has a header, and that header has the word's name by which to find it, a couple of status bits that add a lot of power, a link to the next word in the list so FIND can continue the search if this isn't the one it's looking for, and the address of the code to execute when it's time to execute the word. Following that is the parameter field which could be data, more programming, variable space, or probably other things I'm forgetting.

Thanks Garth!

Before going to college and becoming a machinist I was always much more of a hardware guy, digging through datasheets and assembling things to do the job. Software although I have done it, sometimes confuses the heck out of me.

None the less, my semester is done, calculus is over with till September thank god transcendentals were , so I shale be sitting down and working on my project more or less full time this summer till its done.

I am currently looking at Digikey's catalog, looking for some SRAM. Decided if I am going to have surface mount components I may as well go all out and get a circuit board made up for this project. This gives me the option of using a surface mount xMega64A1 chip, in a TQFP 100 package. Giving me a total 8 serial ports (up to 4 of each of the following TWI/I2C, SPI & UART), and a processing speed of 32mHz. It has a external memory interface that connects RAM right into the microcontroller's available internal RAM.

I am working with Sunstone's PCB software. Getting the layout done today and tomorrow.

Expansion wise I have the following on board. Anything else someone can recommend?

• 1x DE-15 Female Port (VGA Terminal)
• 2x RJ-45 Ports (Cisco Style Serial Cables to take up less space then DB-9 ports)
• 1x RJ-45 Port (Ethernet port using a ENC28J60 Ethernet controller)
• 1x mini-DIN 6 PS/2 Port (Going to use a standard Keyboard with overlay for now)
• 1x JTAG & PDI Header (In-system programming & debugging of the main microcontroller)
• 1x 24-pin Centronics Port (For HPIB Interfacing)

So far I have considerably simplified the design. No more multiple boards, for now, I will just install SPI and UART headers so I can add internal components at a later date.

Dimitri

Taking apart the OLD 5.25 external CD drive I've had for ages. It has a HY534256AS-70 "Memory Buffer" chip in a DIP Socket, anyone can use it?

Not sure of working condition, the product (mainly a PCjr) worked when pulled but was ages ago 7400 RAUL, HD63B03XP, 2x WD16C550.

Also a Sony UV programmable 27C512-15.

Dimitri

Figured I would not have to mention but the above chips are free. They are just taking up space here.

None the less how does this look for the projects case.







I installed the Panasonic drive to test for spacing, the motherboard so to speak will be on the top of the case and the bottom is for the FDD & Power Supply circuit.

And that 256MB SD card will serve as a HDD of sorts.

Dimitri

Then Maxim's SD-card ap. note at http://pdfserv.maxim-ic.com/en/an/AN3969.pdf will be of interest to you.

Depending on your application, you might find you need a lot more access space for I/O connectors than what you can get with a case like that which has only a small panel front and back.

Thank you, printing it now. Nice thing about SD cards is their SPI interface can connect it straight to a SPI port on a AVR if you wanted to. No need to add more electronics, and AVR SD code is "mature" compared to my attempt in this project to interface a 3.5" FDD.

Between USB sticks and CD/DVDs there is no love for the floppy anymore.

I had it laying around with little use (it's 2010 and I still had a Parallel CD drive). Thinking on the back I'll have the VGA, RS-232, Ethernet & PS/2 and in the front the HPIB with room to spare. The SD card will be semi-removable as will access to the JTAG/PDI header it will require the case to be opened.

I was wondering Garth, am I over looking any I/O lines you'd recommend?

Dimitri

The ones you've listed are typical of office applications. If that's the goal, then no problem; but my own use of my home-made workbench computer has made it hard to put in a case like that, because I have

• A/D and D/A inputs and outputs, with reference,
• headers to select DC or AC coupling and bias for the A/D and D/A converters,
• amplifier output to speaker and
• a switch to select which signal goes to it,
• places to plug in anti-alias filters for the A/D and D/A converters,
• 8 oscilloscope probe points for things I sometimes want to watch on the 'scope (like little loops to hook the probes into on the front panel),
• a Dallas 1-Wire port,
• printer port,
• RS-232 ports,
• I²C port,
• 65SIB port (which we devised in the topic starting here, an auto-addressing serial bus that can accommodate a combination of SPI and Microwire devices, dumb shift registers, devices from dumb and simple to smart and auto-configuring, including hubs for further expansion, with interrupt support),
• a port for using the analog oscilloscope for raster graphics,
• PC keyboard port,
• LCD and keypad and header to connect external ones,
• LCD viewing angle adjust,
• a port for an external frequency/event counter that the computer can control,
• a couple of extra synchronous-serial ports interfaced by the 6522s' SRs,
• a MIDI port,
• a place to plug in a wireless data transceiver,
• a port for a tape modem (which no longer has any application now that serial non-volatile solid-state memories have gotten so dense and cheap and dependable),
• 9 status-indication LEDs,
• a 7-position and an 8-position DIP switch to select options,
• RESET button
• ABORT button (like RESET, but not as drastic, only getting the processor's attention with an NMI and not resetting all the I/O ICs, etc.)
• a 72-contact board-edge connector along the back for general I/O for various projects.
• and of course a power connector and maybe a power switch. Batteries would be internal for when I need it in the field and no power source is available.

This is all on a 6.5x4.5" board plus mezzanine. I always wanted to have it in a nice case that could the put in an attaché case, but the requirement of all the connectors and other access has left me unable, after 17 years now, to figure out how to accomplish that goal-- so it still exists in a wire-wrapped contraption on the workbench, with no case.

The next one will have more of everything (I/O, speed, memory, etc.), but better organized, and still hope to find a way to put it in a case, even if that means it must be easily removed from the case to access some of the things-- at least I can take it on the plane to our office in another state when I fly.