|
Not something I toc about very often, but if so, it snooze to me.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
That one just Hertz, period.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
OriginalGriff wrote: Does a clock radio go off with alarming frequency?
every time.
|
|
|
|
|
Only if you leave it out of the fridge... ?
|
|
|
|
|
Since most clock radios use a really annoying high-pitched beeper for the alarm sound, yes they do.
Those among you notice the 'meta' nature of this reply should discuss amongst yourselves while everyone else catches up.
Software Zen: delete this;
|
|
|
|
|
If a clock radio goes off - why is it that the first thing everyone does is turn it off?
Wait - is this back to the no-no thing?!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
|
Accessing a hard disk with an 8 bit processor is a slow affair. No matter how modern that drive may be, you will never get your bytes faster than the processor and the bus can shovel them in.
Serial ATA is no option, simply because my UART and the bus can't keep up with the minimum bit rate. Not by a long shot.
Ok, then it's good old parallel ATA/IDE. The problem here is that even the oldest specification requires a 16 bit data bus. You can use it with an 8 bit bus, but then the upper 8 bits of every 16 bit word would be wasted. You would lose half of your drive's capacity. Since this was last seen on old IBM XT era computers, I also doubt that any reasonably modern file system can live with that.
A common way around this is to put a parallel port between the processor and the drives. That solves the 16 bit problem, but then things get really slow. The processor is more busy with the port's control and data registers than actually sending or receiving bytes. Remember the C64's floppy drives? That sort of slow.
Now, it looks like my little processor's bus is compatible with the drives' controllers. I might even get it to work in DMA mode, speeding up things instead of slowing them down. And I would waste half of the drive's space.
So, what option should I go for? And what file system should I use? FAT16 (or similar) would be the minimum, better FAT32.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
How about something like this[^]?
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
I wish it were that easy, but setting up the tiny computer as USB host is even more complicated.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 1-Jul-20 10:16am.
|
|
|
|
|
I know it's complicated but this [^] might help.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Quote: it includes no PC host USB driver development facilities
Sounds like the microcontroller is set up as USB client with a PC as host. I would have to set up my coputer as the host, and that might be a little more complicated. Let me first build something that can load and boot an operating system before I write the OS itself.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Never used LUFA and know little about it but I have seen a lot of people use it and thought it might help.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
I doubt that any older 8 bit CPUs would make a good USB host. The old UARTs or USARTs don't even support the minimum bit rates and even with DMA you would struggle to get that stream of bytes through the bus in real time. Clients like a USB mouse or keyboard, which only snd a few bytes at a time, may be ok, but nothing that sends larger streams. As cool as USB might be, but I'm not sure if the effort to build it would be worth it, even if the lower bit rates are a lesser problem.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: And I would waste half of the drive's space.
With today's large drives, wasting half of the drive's space isn't a major issue today. The question is compatibility - (1) will any platform other than yours be able to read the disk, and (2) do you care?
I'm sure that circuit diagrams exist for the PC/XT's 8-bit disk controller and for other disk controllers of the same vintage. If that supported disks with a 16-bit bus, could you not cobble up something based on them to perform the 8-bit to 16-bit transfer?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Quote: The question is compatibility
My 'drives' will probably be Compact Flash memory cards. It would be really nice to do all the software develpment on a PC, copy the results to the memory card and then plug it into the 8 bit computer.
Quote: I'm sure that circuit diagrams exist for the PC/XT's 8-bit disk controller and for other disk controllers of the same vintage. If that supported disks with a 16-bit bus, could you not cobble up something based on them to perform the 8-bit to 16-bit transfer?
It's absolutely simple. You just did not hook up the data lines you did not have. The upper half of a 16 bit word would simply not be used. The controller would not know about it and simply write or read these upper bits to the drive anyway. That's the point where you lose half of your disk's capacity.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
You may add two extra processors to read and store the upper and the lower bytes for you...
These two may work as a DMA toward the disk for your main processor...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
That's an idea. Holy overkill. Little 1802 says no to that. It never lets go of its bus for anything. Instead of simple 'shut up, processor' type DMA, it alwayskeeps running its program and throws in an extra DMA cycle with every instruction as long as DMA is requestet. It does all memory addressing itself and the requesting device just has to put its byte on the bus at the right moment. Two of them would start to scratch each other's eyes out.
Another thought: I can't really believe that they wastet half of a drive in the old days, just because you happened to have an 8088 processor. These drives where small and cost more than their weight in gold. Maybe there is something in the IDE drive's controller, perhaps in the control register, to tell it that we are running on only 8 cylinders.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Talking of overkill... You mentioned the 1451... It had a 6502 inside just the same run the whole C64...
Maybe some shif-registers on the data lines can help you out?
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
The processor board on the C64's floppy controller board had a little more to do, so it actually was not overkill.
For one thing, it controlled the stepper motors of the drive and the analog signal to the head directly. Look at other disk controller boards of that time (which could control several drives) and you can see that it was not a bad idea to put a separate processor on the controller board and let the computer's main processor do something else in that time. Each drive had its own controller, so multiple floppies could also work at the same time, unlike when you have only one processor and a central controller.
And then they did something really good: The processor on the controller also handled the file system. Indeed, the entire disk operating system of the C64 ran on the controllers, not the computer. The computer just sent DOS commands over a serial port and received the results the same way and otherwise needed no proccessor time or memory, both not overly abundant on a C64. And it could still have multiple drives working at the same time without additional cost.
Overall, it was very slow, but not because the concept was bad. The serial connection had a hardware bug, which was discovered when production had already started. The best thing they could do at that time was to do a quick software patch on the units that were already built, which was awfully slow. later they had to stay compatible to their older hardware and had to keep it that way, so it was officially never corrected. not even when the hardware bug had been fixed and newer drives could have been significantly faster.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
TurboDisk to the rescue!
Software bolt-on that increased floppy loads by a factor of 10.
The original version I had was a Basic program typed out of a magazine that would load some asm code to a fixed address. I disassembled it and figured out which op codes to tweak to load it wherever I wanted. C64 was a great learning machine.
|
|
|
|
|
Is there an SPI interface on your processor? might be easier to use SD cards...
|
|
|
|
|
No, the processor is from 1976. But a PIC microcontroller could actually help. Onw with a PSP, a USART for SPI and plenty of I/O pins. The old processor would talk to the PIC over the PSP, SD cards would be hooked up to the USART in SPI mode and the normal IO pins would be used for the IDE interface. There is even a library for the FAT32 file system, so that the PIC could also take care of all that.
I even have o suitable PIC here, but the IDE does not support it.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
Little CDP1802 never needed a DMA controller. Indeed, at no time it gives up control of the bus for any other devices, nor does it ever stop executing instructions. Instead, it throws in an extra bus cycle with every instruction when DMA is requested, does all the memory addressing itself and signals the device to put its byte onto the data bus or take it from the data bus. It is its own DMA controller and allows DMA for devices that normally would not be able to control the bus themselves.
On top of that, it also has another operating mode, the load mode. If you switch the processor into load mode after a reset, it will not execute any instructions, but serve DMA requests. This was used to read from the hex keyboard and at the same time to output the byte you had entered on the LED display. This way you could enter and run programs without any software and only simplest hardware involved.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
