6502.org

Mouser also has the 626-DLP-UM245R module for $20. These would be a viable option for a terminal interface on the daughter board.

Daryl

Well spotted, I didn't notice that one. Looking at the datasheets, it looks like the 245R is cheaper than the 245M because the R has more components built into the chip, other than that they seem about equally capable. One thing I don't like about the R compared to the M is that the R's pinout is likely to make a single sided PCB a bit messy (the M has D0-D7 all neatly next to one another while the R has them all over the place and not in order). If the plan is to have a dual sided PCB, then it's not as big a deal.

If you intend on running one, and only, one application over the link, that's fine. Otherwise, you're MUCH better off going with TCP/IP. This way, you at least could manage multiple logical connections to the computer (e.g., using a terminal of some kind at the same time as transferring a file). Implementations of TCP/IP are freely available as part of the Contiki operating system, for example, or self-standing via the uIP package.

I've been working on some thoughts....

We use a 65C02 with jumper options for a 65C816. We use a TTL OSC for the clock (the user can choose their own desired frequency) and a reset switch (or reset device like the DS1813, etc). Add a pull-up resistor SIP pack for the NMI, IRQ, RESET, BE, etc.

We use three 28 pin DIP sockets for the memory. One could be jumper-enable to support 27256 EPROM or 28356 EEPROM. The other two would be for SRAM0 & SRAM1 (optional). We could also add pads for a .3" wide DIP for the Cypress SRAMS.

If we choose to use the GAL 16V8 for the decoder, here is how I was thinking of using it:


The CLK2 and R/W would be used to decode /MRD & /MWR outputs such that either would only be active during the CLK2 logic high state.

The Address inputs will select RAM0 when A15 is low.
RAM1 or ROM will be selected when A15 is high, based upon the switch input. In either case, RAM1 is written when A15 is high.

The /VIASEL line can be placed anywhere is the address space that we desire... $FExx, $80xx, $7F00, $02xx, etc. The associated RAM or ROM would be deselected for that page. We connect /VIASEL to the /CS2 input on all VIA's and then put A4 in VIA1 CS1, A5 on VIA2 CS1, and A6 on VIA3 CS1.

A7 can either be used for a 4th device, expansion port, or we can decrease the IO space to 128 bytes.

Finally, we provide connectors for the IO pins on VIA1 & VIA2. For VIA3, we place them such that a daughter board could be attached to handle the desired Human Interface.

I suggest using standard pin header pads on the board and using the 90 degree pin headers and using standard ribbon cable to tie the boards together. This should prove less expensive than the stackable connectors. You could also provide pads on the top & bottom edge of the board and split a pin header between the board.

Has anyone tried this?



Any comments?
Daryl

Most printed circuit boards are substantially thinner than the 100 mil spacing between IDC connector pins. You'll invariably end up having to bend pins manually.

Also, I'd rather that the RAM/ROM control pin be controlled electronically. Mechanical switches can bounce, and if the CPU happens to be executing RAM or ROM code at that point, you'll cause the machine to crash. With the transients it might produce, you just might crash it anyway.

I would also suggest "RAM write-through", as was done for the Commodore 64 and 128. That is, to copy ROM into RAM, you just do this:
(As a programmer for the 65816, I really had to think about how to write the above code. The 65816 would handle this problem with the greatest of ease!) Anyway, after the loop completes, you're then free to soft-switch out the ROM, and then you can "patch" the ROM via its RAM copy.

I will test fit a header on my boards from ExpressPCB when I get home. if it doesn't fit well, then the 90 degree pins might be best.

As far a switching the RAM/ROM, electronic bank switching would be nice, but I was going for simple. my thought was to have some code running in the lower RAM that waits in a loop and prompts the user to toggle the switch now, and press enter when done.

The idea here being to copy ROM to RAM, or download your OS from the host into upper RAM, then switch control once. the ROM could have the code needed and perform the copy down to RAM.

If you have a low-complexity bank switch method, I'm all for using it.

As stated, any write to the upper 32k would be to RAM1, regardless of the switch position. (RAM write through). We could modify that as well... remove the A7 input and replace it with another switch.

We can certainly tweek this. We may even want to look into a GAL 22V10
to carry the bank select logic as well as the address decoding.


Daryl

Wow, a TCP/IP stack for a single-digit MHz, 8 bit CPU. Now I've seen everything

I wasn't thinking of making my little box multitask, it seems like overkill for something with less than 64KB of user memory (I may have 2 tiered device drivers, but that's it). The "beauty", if you can call it that, of my idea is that it lets you multiplex a moderately complex UI and binary data transfer over a single cable, and I can access all that from a PC/Mac using a standard-ish app (a terminal emulator) without the overhead of something like an X server. I'm going to assume there's a chip or demo board somewhere that works the same as the USB245, but for ethernet instead of USB. If I used that instead of USB or RS232, how would I access my little box from a PC?

<plug type="soapbox" language="Forth">HAH! You obviously don't know the power of the Forth! </plug>

Seriously...

It depends on your application. If you're only doing one thing at a time (not to be confused with running one program at a time), then a terminal interface is fine. Otherwise, you will need to multiplex multiple data streams over that single cable. For utter simplicity, I'm a fan of ATM, but you'll need to write a custom ATM switch on the PC. Probably not what you're looking for.

IF, and I repeat this, *IF* you do go with TCP/IP over the serial interface, you can use PPP or (preferably, since it's simpler) SLIP, both of which I know Windows supports via its dial-up networking support. You may need to install it separately on modern versions of Windows, since few people have modems anymore.

For Linux, it's the same thing -- you need to set up a PPP or SLIP driver.
Not sure what you mean by two tiered device drivers, but if you use something like Forth for programming it, the compact code representation offered by Forth when compiled definitely allows for TCP/IP to be implemented. Contiki is an OS for the Commodore 64 that supports TCP/IP.

Note that you're not going to get Unix Workstation Class Networking . But it is doable.
Well, if you're going to provide *graphics*, then RFB is the protocol to use. RFB is the Remote Frame Buffer protocol, and that's what VNC uses to transfer graphics back and forth. I've found that, for many applications, it's actually faster than X.

But there is nothing preventing a text-mode UI from being used with TCP/IP. In fact, I encourage you to "telnet uncensored.citadel.org" if you don't believe me.
I used the PacketWhacker on a ATmega project once, but I *never* got the poor thing to actually work. The documentation in the $20 book that accompanies it is woefully inadequate to debug it with as well. The actual device datasheets were thoroughly unhelpful as well.

That being said, let's suppose you find one that you can get working at all, let alone well. The simplest method of accessing the device is through telnet. A telnet connection is just a dumb socket connection -- no encryption at all, and unless the *server* on the other side asks for it, no need to password authenticate either. Yeah, there are options you can support to communicate things like terminal size, echo settings, etc. But those are extra credit items. Telnet is, at its core, an otherwise unadorned TCP stream that delivers raw bytes (usually with VT100 escape codes if it's text) from the device, and whatever you type in goes the other way. In other words, Telnet emulates a modem.

(Note that HTTP, SMTP (e-mail), POP3 and IMAP (also email), FTP, etc. all are just glorified telnet sessions. In fact, you can do this:- and when it responds, type this: And you'll get the Google homepage, expressed as raw HTML, and all the MIME headers to go with it. Yes, folks, that's what your 5MB to 10MB Internet web browser abstracts away from you! Want to check your mail? OK: But, I'm really digressing now. )

I came up with a system using two 16V8s as shown below. The first PLD does coarse address decoding for two 32K memory areas (LWR & UPR), zero page (ZP), an I/O page (I/O) and a switchable 4K ROM (ROM).

The second PLD subdivides the I/O page for the two VIAs (VIA & VIB), generates RD/WR signals and a flip-flop controlled ROM enable signal (ENB) which is initialised with a reset and cleared by a write to zero page.

Full schematics here:
http://www.obelisk.me.uk/forum/sch1.gif
http://www.obelisk.me.uk/forum/sch2.gif

Edit: Fixed URLs

@kc5tja

Hmm, that's quite interesting. I knew about telnet (used to play MUDs back in the day), but I always thought it was straight text with no control characters other than what low ascii gives you. When I say UI, I mean something like the old Borland text mode stuff, implemented using something like the C64's "[home][crsrdn][crsrdn][crsrright]hello", or maybe something a bit more complex; but definitely not pixels. If telnet does give you that sort of control I may go for that, but I'll have to decide if the added complexity is worth it for my very limited first effort.

What do I mean by a two tiered device driver? it's a fairly common technique, but it's got a zillion names so you probably know it by a different one. Basically, you write the device driver to have two parts, the bit banging part which usually consists of little more than an interrupt handler and must finish quickly so as not not affect the machine's performance; and the calculating part which is run on a lower priority interrupt or as a regularly scheduled task. This part does all the more time consuming stuff, since it's not as timing critical. For example, consider a synchronous serial comms port using two VIAs. You'd have a SR interrupt that gets triggered when a byte gets shifted in, the ISR would fetch the byte from the VIA's SR and append it to a queue so as to free up the VIA as soon as possible so it can receive the next byte. There would also be another interrupt on Timer 1, set up to trigger at say 50Hz. The ISR for this other interrupt would get the bytes from the queue, run a CRC calculation to make sure the data arrived correctly and set some flags based on the message. You could have done all this in the SR ISR, but that ISR would either have been a lot more complex to handle the case where a new byte arrives while it's still busy calculating, or you would have had to slow down communications to make sure no bytes are lost or maybe implement a handshaking protocol. Instead, since the SR ISR is so small that it can do its job while the next byte is still getting shifted in, we can have a fast and simple device driver.

About Forth... I'll have to look into it. I'm not a huge fan of reverse Polish notation (especially after I found out how simple it is to convert regular "human" infix notation into postfix), but it looks like 65xx CPUs seem to be optimized for the Forth way of doing things. Definitely worth looking into.

DANGEROUS. I strongly do not recommend this approach, because ROM needs to access zero-page. You might think, "So copy ROM to RAM first." But, why have the ROM at all at this point? Having the ability to use the underlying RAM independently of the ROM is powerful.

I strongly prefer just using a bit from a VIA somewhere. You just can't get any cheaper than that. If that takes away from bits you'd use for other things, then use the VIA's serial port to talk to one or more 74595s, with a single bit to publish the serial data when you're done loading it.

The simplest possible design always fulfills two goals: it communicates intent to the code or schematic reader and it involves the least number of design tradeoffs.

I opted for this approach (in this design) because I wanted to be able to evict the bootstrap O/S after start up and have a full 64K of RAM for application (except for the I/O page). My boot kernel executes a series of LDA $F000,X STA $F000,X LDA $F100,X STA $F100,X ... instructions in a loop on reset to move to the bootstrap to RAM none of which needs access to zero page so the approach is actually pretty safe. I could have used any page as the trigger but zero page works just fine.

In an earlier post I suggested we could use another processor to take control of the bus and load the O/S into the RAM but this requires more glue logic to gate the control signals which aren't affected the the bus enable signal (and the data/address bus lines on the older rockwell chips). I like the idea and am using it in another design but I had to switch to much bigger PLCC based PLDs to get the number of I/O lines I need.

As for using logic controlled thru one the VIAs, yes you could but you'd also need logic around it to make sure that the ROM is enabled on reset so I not convinced it ends up being any simpler than my two PLD design.

Most flipflop chips have reset inputs. I'll just leave that as it is.

I remembered to test fit my ExpressPCB boards. While there is some play, it looks like you could do it.

Daryl

Why not use a 22V10, decode A15 down to A4, and dedicate one of the blocks to either an internal flip flop or an external one. This way, you have defined control over the bank switching. Using two GALs adds propogation delays, and I'd like to make this thing capable of higher speed (especially since we won't have any slow 65C51's hanging on it.)

Daryl