New Guy - With Project!

[Dimitri]

GARTHWILSON wrote:

The next time I have to develop something involving any of several serial protocols, it will be on 65SIB.

Sounds neat, well 65SIB will be a external interface on my project. I will have a 2x10 .100" header just for it.

Does the current 65SIB define any standard I/O commands or no?

Dimitri

[GARTHWILSON]

Quote:

Does the current 65SIB define any standard I/O commands or no?

Mostly it will just be the commands used by the devices you put on it, which will be in the data sheets for those ICs, whether memories, UARTs, data converters, or whatever. There are thousands of them. Chains of dumb shift registers like the 74HC595 can also be put on it, which really have no software protocol themselves as it's not applicable.

For advanced devices capable of autoconfiguration (which can reside on the bus at the same time with less-intelligent or even dumb devices), Samuel Falvo was going to write up the software protocol for that since he is ahead of me on that kind of thing-- it's just that things move slowly for us except at the times it becomes part of our work, especially an urgent part. The less-advanced devices simply will not respond to autoconfiguration polls and so on, so they can reside peacefully with the more advanced devices, and operate normally.

I had in mind how I wanted to work the expansion hubs, but I have not gotten around to implementing it. It would be with a PIC microcontroller and something like the 74HC125 tri-state buffer.

I guess I need to make it a higher priority to get a summary of the 65SIB specification put out here. [Edit: Done, at viewtopic.php?t=1064&start=105.]

viewtopic.php?t=1350 is a related topic, geared around how the controller and devices handle their messages, not so much how the 65SIB carries those messages. Note that the "65SPI" chip Daryl refers to is an IC he makes available and is of his own design in programmable logic. Don't confuse 65SIB with 65SPI. Although they can be used together, they're not the same thing. Also, the 65SPI is specifically 6502-bus-compatible, whereas 65SIB can be used with any processor but was devised on the 6502.org forum.

This topic might also be of interest. (The URL here jumps into the third page of it.)

[Dimitri]

Thank you,

I am going to layout the hardware for 65SIB but will wait on actually using it. Hopefully by then you and Samuel will have had time to standardize it.

The Auto-config I was thinking of the card bus for mine will have a handshaking system set up like a Linux shell kind of.

A handshaking of a FDD controller (in slot 0) on PCIAVR.

Northbridge -> Device Ready?
Card0 -> Ready.
Northbridge -> Commands?
Card0 -> 7
Northbridge -> Send
Card0 -> RDFL
Card0 -> WRFL
Card0 -> DLFL
Card0 -> NWFD
Card0 -> DLFD
Card0 -> FRMT
Card0 -> EJCT

So in terminal or a "program" when one of those commands are entered my "OS" will take the command, realize its not local to the CPU, send it to the Northbridge with the variables. The Northbridge finds in RAM as belonging to Card0 and send the command with variables to the FDD card in slot 0.

So running it

Quote:

Root: RDFL
RDFL needs a variable
--- report.txt
--- picture.jpg
--- source.c
--- /new
------ labdata.txt
------ testdata.txt
Root: RDFL /new/labdata.txt
Opening Text Editor....

As a running example.

Dimitri

[kc5tja]

Dimitri wrote:

GARTHWILSON wrote:

The next time I have to develop something involving any of several serial protocols, it will be on 65SIB.

Sounds neat, well 65SIB will be a external interface on my project. I will have a 2x10 .100" header just for it.

Does the current 65SIB define any standard I/O commands or no?

Dimitri

Once upon a time, I was working on my own 65816-based home computer, which I wanted to replace my PC with. I came up with a system for auto-configuration over an SPI bus. Eventually, collaborating with Garth, this evolved into two standards: 65SIB, which is the hardware standard, and the software standard which sat on top of it, and which was optional.

Unfortunately, I've lost the software standard, and can't find the documents for it. It was never implemented anyway, since I still don't have a 65816-based computer to play with.

[Dimitri]

kc5tja wrote:

Once upon a time, I was working on my own 65816-based home computer, which I wanted to replace my PC with.

So you wanted a 8-bit computer verses your current 32/64-bit desktop?

Dimitri

[GARTHWILSON]

Quote:

So you wanted a 8-bit computer verses your current 32/64-bit desktop?

See especially the last couple paragraphs of his post at viewtopic.php?t=39&start=34 . Actually, I think you'll like the entire thread!

[Dimitri]

Garth,

I looked at that thread, and I do like what I see. I reinstalled Linux on my desktop now that I built my youngest brother his own computer, and no one else is using my computer at all. So as I finish the hardware specifications I will be learning Forth, that way once the software development phase happens I can figure out a way to develop a Forth interpreter with functions for the system built in.

I like the idea of a built, non-customizable, system. Maybe I'll have the CLI shell, a text editor, and a Forth Interpreter as the core of the system. Additional functionality can be programmed in the text editor, then the shell can access it and run the interpreter to run the code.

Forgot to add there will have to be a 2nd interpreter for HP-41C* programs. To access the large compilation of HP-41C* programs out there.

Dimitri

[kc5tja]

Ahh, yes, all my points in that thread still hold today, though it seems the available hardware has kinda sorta collapsed into a certain meta-stability that allows easier maintenance.

Still, the very model of use that I envisioned when I wrote that post can be seen in today's iPad. It is, however, regrettable that the iPad isn't an open platform. That, too, is a requirement for me.

Maybe someday, a tablet PC with Android will come out, and I can try to play with that instead. Except for I/O expandability issues, it would virtually eliminate my desire for a 65xx-family PC.

[Dimitri]

Check out the Archos 9, when I am not tied to my desk its what I use.

Netbook internals save for the touch screen. And as it comes its more capable then the iPad.

Dimitri

[Dimitri]

I got to ask, since one requirement of my system is a floppy drive and buying a controller chip is more or less out of the question since no one will sell them in quantities of one.

I have been the last 3 days reading up on the IBM tech sheets for them and I think I can "roll my own" controller. Using my PCIAVR interface (It is pin compatible with 65SIB somewhat, it will work). Would there be any interest in such a controller for other projects?

I can give the circuit diagram/board layout and binaries for the AVR if you want it once I'm done.

Dimitri

[Dimitri]

Code: Select all

     +----+----+
/D0  |  1 |  2 |  GND
     +----+----+
CLK  |  3 |  4 |  GND
     +----+----+
MOSI |  5 |  6 |  GND
     +----+----+
MISO |  7 |  8 |  +12V
     +----+----+
/D1  |  9 | 10 |  +12V
     +----+----+
SEL0 | 11 | 12 |  /D2  
     +----+----+
-12V | 13 | 14 |  /D3  
     +----+----+
/Y0  | 15 | 16 |  GND
     +----+----+
/Y1  | 17 | 18 |  /Y2  
     +----+----+
GND  | 19 | 20 |  /Y3
     +----+----+ 

/D0-/D3 are Data input (Board to Card) while /Y0-/Y3 are Data output (Card to Board).

SEL0 is on the same pin as SEL1 or /DS0 on 65SIB, as my cards get their Slave line based on their card's connector on the board.

Pin 8 has a regulator provision to go from 12V to 5V and Pin 10 from 12V to 3.3V depending on the boards requirements.

Otherwise the SPI locations are the same. So they are interchangeable more or less.

Dimitri

[kc5tja]

Dimitri wrote:

I got to ask, since one requirement of my system is a floppy drive and buying a controller chip is more or less out of the question since no one will sell them in quantities of one.

I personally don't have any need for such, but were I to require a floppy drive, I would use the same technique the Commodore Amiga used: a dumb serial shift register, driven by DMA, with software MFM/GCR encoding. This gives me the greatest possible flexibility, at some performance cost, and even gives me additional space, because inter-sector gaps don't have to exist when you perform full-track transfers. (This is one of the reasons why the Amiga pulled 880KB out of the same media type as the PC/AT's 720KB disk. An extra 160KB won't hurt anyone, right?)

[Dimitri]

Yes I've read about the "tricks" used to gain more memory space. The team at Apple did similar.

The Amiga used the "Paula" chip to control the FDD. But I don't know much about it. The Commodores to use higher densities had to spin high density disks at half the speed to get the with the chipset. Personally I am looking for PC compatible for now to work with industrial CNC machines first (as that is my field). Then perhaps I can rewrite the AVR code I'm writing to work with "non-standard" disk formats.

In theory a 1.44MB floppy can be made to hold 2MB of data. If a non-standard encoding is used. As can the old 2.88MB disks can in theory hold 4MB.

Dimitri

[fachat]

kc5tja wrote:

I personally don't have any need for such, but were I to require a floppy drive, I would use the same technique the Commodore Amiga used: a dumb serial shift register, driven by DMA, with software MFM/GCR encoding.

The older Commodore floppies even used this technique without DMA...

Quote:

(This is one of the reasons why the Amiga pulled 880KB out of the same media type as the PC/AT's 720KB disk. An extra 160KB won't hurt anyone, right?)

... and were even able to put about 1M onto DD disks!

The older, "parallel" disks drives used a ROM as GCR decoder - very intelligently made to use the same ROM back and forward! The newer "serial" drives used software GCR encoding.

André

http://www.6502.org/users/andre/petinde ... index.html
http://www.6502.org/users/andre/petinde ... x.html#gcr

(edit: Commodore floppies as in pre-Amiga, i.e. PET and C64 disk drives :-)

[kc5tja]

Dimitri wrote:

The Amiga used the "Paula" chip to control the FDD.

This is a common misconception; it's not really true.

They used the CIA chips to actually control it (drive-select, motor on/off, step direction, step movement, is the disk in the drive? etc.). The Paula chip is nothing more than a serial shift register which reads bits raw off the data line, shoves them into 16-bit words, and then tells the Agnus chip when to stuff a word into RAM (or fetch a word from RAM if you happen to be writing data). It's simplicity is stupifying.

The Amiga uses its blitter (the same feature responsible for lightning-fast graphics updates) to perform MFM (de/en)coding. This permits the computer to process up to three tracks of data at once (and why trackdisk.device always had a minimum of 3 diskbuffers allocated). One is being DMA-ed into RAM by the Paula/Agnus combo. One would be decoded by Agnus. And the third would be processed by the 680x0 processor for filesystem operations. So, if you think the Amiga's floppy interface was slow compared to other computers, keep in mind that most of that sluggishness was in the filesystem driver, not in trackdisk.device. Anyone who has played "Space Ace" on the Amiga knows exactly how fast the floppy could be (30fps, full-screen, 384x240 resolution, HAM video mode animation -- off of a floppy disk!).

Quote:

The Commodores to use higher densities had to spin high density disks at half the speed to get the with the chipset.

This saved the cost of having to re-engineer the Paula to have a 1Mbps shift register instead of a 500kbps shift register (which all floppies made up until HD was introduced used; 250kbps, used for 360K media, could be effortlessly emulated by just doubling up on the bits when you shifted them out).

Quote:

In theory a 1.44MB floppy can be made to hold 2MB of data.

1.8MB seems more reasonable (the Amiga's full-track capabilities have 1.76MB using the OFS filesystem). The reason you won't be able to pull a solid 2MB is because of encoding and synchronization issues. For example, because the Paula essentially used a single monostable multivibrator for its read path, you would lose about 4 to 8 bits worth if MFM every time the head would step or the motor started. As a result, you need at least twice that for a gap, both in front of and behind a special invalid MFM sequence which signals, "Hey, the start of data is here."

Although, if you used GCR instead of MFM, or even RLL encoding, you could probably pull off 3MB to 4MB. But, you'll probably be dealing with motor speed control tricks again to get the precision timing right for the interface chip.