|
BALL!!! We've eyeballs.... 
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
Yes, but what you wrote does not mean what you think it does.
|
|
|
|
|
But it'll still all end in tears.
|
|
|
|
|
Indeed, with a degree in English, I purposed it just as written. So, ROLL with it! haha 
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
MacSpudster wrote: with a degree in EnglishAmerican
FTFY 
|
|
|
|
|
So, you have a degree in English and came to study literature on Codeproject?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
MacSpudster wrote: pulls over to the side of the road to ball
Classic.
|
|
|
|
|
I always wanted to ask such a *smart* question, especially right here. I will take care of the codez myself, but I need an idea, which file system to use once I get this working.
I'm building my own IDE/ATA port. The hardware part is almost too easy: A Intel 8255 parallel I/O port provides 24 I/O lines, enough for the ATA interface. Let's keep everything in CMOS, so it's going to be the 82C55. Hooking this up to the processor's bus is nothing special. It will get one of my chip selects and a 16 byte address space for memory mapped I/O.
So far, so good.
Now I have downloaded the ATA specifications. Bla, bla, bla, data registers, bla, bla, bla, status register, bla, bla, bla, command register...., bla, bla, bla, cylinders, heads, sectors, bla, bla, bla, or better use LBA mode...
It all comes down to setting up the 8255 to read or write 512 byte sectors from or to the disks, a 16 bit word at a time. Does not sound so hard. Let's add in some status and error checking.
Now comes the really tough part: Up to here I can identify the connected drives, read sectors and write sectors. I need a file system. This simple ATA interface can support drives up to 128 GB. FAT16 or FAT32 would not be sufficient and I would not really enjoy implementing something as FAT as NTFS (pun intended) on a 8 bit computer.
Any ideas for a lightweight alternative?
Edit: FAT32 may work, but then I would have to partition the drives into up to four partitions of max. 32 GB each.
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.
|
|
|
|
|
FAT32 supports bigger than 32GB - unless you listen to Microsoft!
I have several 128GB FAT32 single partition SD cards, simply because they are accessible by both Windows and Android. FAT32 128GB - Google Search[^]
Individual files on a FAT32 drive can’t be over 4 GB in size—that’s the maximum. A FAT32 partition must also be less than 8 TB
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That would probably more than what I would ever need. Let's hope that FAT32 does not demand more than a 8 bit processor has to offer.
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.
|
|
|
|
|
That's going to be down to your choice of processor, and your coding abilities! 
What processor are you using? I'd have thought a eight bit was a bit too much of a PITA given the normal address space is so limited.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: What processor are you using?
Is that really a question? Greatest little 8 bit processor to ever go where no man had gone before. (CPU History - Computers and CPUs in Space[^]) 
OriginalGriff wrote: I'd have thought a eight bit was a bit too much of a PITA given the normal address space is so limited.
The address space is limited, but not the total amount of memory anymore. A 512 kb SRAM costs about 3 bucks now. The best I could do is to address this memory in chunks of 32k at a time.
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.
|
|
|
|
|
Hah! The Z80 was better!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Snobs. They were so conditioned to jump at everything that looked like intelesque CISC architechture that they were not able to comprehend something like RISC. They called it 'weird'.
If I did not have to look for it, I would now dig out some old newsletters where two guys, one with a Z80, beat each other in several rounds in optimizing some code for their processors and running it faster than the other.
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.
|
|
|
|
|
I like RISC, but CISC is good as well.
If you like RISC have a look at ARM: that's the most complex RISC I've ever seen!
(Fun to work with in assembler though - nice architecture.)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's one reason why I keep that old little processor. Within an hour I could explain to you all that you need to know to get working with it. The other reason is that the parts, devices, software and tools I need are very inexpensive by today's standards. And I hate soldering SMDs.
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 hate soldering SMDs.
I'm with you on that one: Herself used to hand solder 304 pin QFP (0.5mm spacing) processors onto prototype boards for me but there's no way I could do that (and she used a pic'n'place / reflow oven combo for production stuff) - I used to hate changing SMD resistors! PTH was sooooo much easier to work with.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
have you considered the unix file system (UFS/UFS2)?
it's an oldie but a goodie, robust, fast and easy to understand and debug (coding is straightforward without the need for a PhD in mathematics).
Supports partitions, block and raw access, comes with a bunch of tools for managing/checking.
There's source code out there in old fashioned C (i.e. not some modernised version of the C language) so even hand converting it to another language not hard. (Ust remember how pointers, pointers to pointers, array offsets from pointers work for the table lookups such as the inodes).
Probably could even find a C compiler to output assembly/machine code for the processor of your choice if that's the way you are going.)
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Lopatir wrote: Probably could even find a C compiler to output assembly/machine code for the processor of your choice if that's the way you are going.)
I have a C compiler, so this might actually be worth a try.
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.
|
|
|
|
|
Ext2 could work but I don't know how heavy it would be in terms of code complexity and it would limit the portability of the files.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Ah, Linux and also close to the already suggested Unix file systems. Good candidate.
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.
|
|
|
|
|
ext2 will be difficult and overkill and need a lot more code & complexity and wont leave much room for anything else
compared to UFS which could run (as just one part of the unix operating system) on PDP-11's with 64k memory (and still leave room for multi users running multiple programs) - sure the PDP was a 16 bit machine but it's instruction set was not too far off the Z80 - so code sizes would be comparable. (OK, no paging, no clock interrupt) but those can be fudged/arranged.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
The PDP Macro-11 Assembler and Resulting Octal instructions were NOT Z80.
they were clearly similar to the Motorola. We had R0-R7 and most C (written for PDP 8 I believe),
instructions were a SINGLE Macro-11 Instruction, including Register Indirect moves!
You could increment and dereference any register. The Intel chip has a single accumulator, ugghh!
When I switched to Intel 8080 for the IBM PC... My first thought was "So this is what the 60s felt like!"
|
|
|
|
|
Kirk 10389821 wrote: The PDP Macro-11 Assembler and Resulting Octal instructions were NOT Z80.
Never said that, I actually wrote " was not too far off the Z80"
Way back then I and some other enthusiast nerds did "hand assembly" (instruction set reference manuals and pen + paper) for [mostly] Z80, PDP, 6502 machines, the instruction format and binary structure, names and even more the hex/binary pattern (i.e. which bits were the instruction and which were register bits) of PDP-11 and Z80 were quite similar and, and way easier to translate code PDP<->Z80 than to/from 6502. (such as translating the guts of MBASIC - excluding the I/O of course.)
Yeah I know PDP usually meant octal, but we annotated the PDP manuals with hex, that further made it easier to move between processors (and did further enhance the Z80/PDP similarities / instruction binary style).
On the surface Z80 seemed to have the best set of instructions, but PDP had the best power of instructions - as you mentioned PDP could do pretty much anything with any register, with Z80 a lot of time was spent switching data back and forth between regs (which in hand assembly is painful coz half a page down you have to keep remembering where you left what and if you need to change it around again again again or if it's already changed around).
Once was young and stupid, thankfully not doing (nor contemplating) that [stuff above] anymore.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Octal vs Hex... Then again, they used 2 Byte Words...
Later in college I wrote my own MicroCode and learned how instruction sets are created.
Again, the HUGE Disparity in General Register Usage meant the instruction sets were not THAT close.
For example, EVERYTHING you see in C is basically a single instruction on the PDP!
And after 35 years, I find it hard to remember the actual assembly lines, except I know 4747 in octal was the JUMP instruction.
Yeah, abstraction is the key to working faster. I wrote some Intel Assembly to do some fast calculations... When I was done, I saw that the optimized C version was like 99% as fast. It took me 40hrs in Assembly. The C implementation was closer to a day (including testing/comparing to Assembly).
At that point, I NEVER went back, except when I had to write a thunking layer and forcibly execute 32bit code on 16 bit Windows... Even that was 2 lifetimes ago.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
