[ColorForth] USB and other serial bit boffing

[Myron Plichota <myron.plichota@xxxxxxxxxxxx>]

> Tell us more about the motherboard you're using. Most motherboards I've
> seen have serial ports on them. Failing that, there's usually a parallel
> port; that would be much easier to interface a serial device to (you'd
> have to implement a software UART and have some level translation
> circuitry out there...).

2 problems:

1) The PC87 and PC98 roadmaps are mandating the total discontinuation of 
"legacy" serial and parallel ports (and floppy disks). Although motherboards 
still are available which provide them, laptops usually do not anymore. The 
PC is moving further away from a simple hacker-friendly (well, kind of) 
machine and squarely into the big bu$ine$$ trap and is now totally useless 
for hackers, scientists, and engineers to casually cobble up a simple 
interface to another piece of hardware sitting on the lab bench. Treasure 
your old machines: they are literally irreplacable.

I'm sorry I don't have a URL ready for this post, but any search engine 
should give you lots of hits on PC97 or PC98 or PC_God_Knows_What.
I have them as PDFs, and at least I know what writing is on the wall, much as 
I dislike the news.

2) The wait states used to slow down accesses to the parallel port (if it 
exists!) limit the bitrates you can achieve severely no matter how fast your 
CPU is and there will be timing jitter due to interrupt and DMA activity. I 
would not count on a standard USB peripheral's ability to adapt to 
non-standard bitrates (standard = 1.2 and 12 M bits/sec) and a whole lot of 
jitter.


The only relatively simple idea I have right now that may rescue the notion 
of casual invention on the PC is to develop a PCI card that provides 
equivalent and hopefully better I/O than the past and limit the software 
hurdle to mastering the art of PCI bus interfacing. Note that this does not 
solve the problems involved with dealing with the gazillion different 
motherboard chipsets, video cards, floppy disk controllers, etc., etc.

I have been experimenting with flat protected mode x86 code quite a bit 
lately, and have been smacked in the face by the hardware incompatibilties 
encountered when testing it on the various x86 PCs at my disposal. VGA color 
text mode 3 (inherited at disk boot time), and LBA ATA (aka IDE) interfacing 
(simpler and more uniform than floppy disk!) are one of the few constants I 
have learned to trust, and those are hints to any colorForth codesmiths that 
have the desire to release a generic normal character set version that anyone 
can run without hardware compatibilty problems. Of course, one needs a spare 
hard drive to play with, perhaps a tiny, orphaned 200 MB unit ;)

I can contibute the DOS utility I have written (in NASM) to overwrite an LBA 
hard disk from the MBR onwards with a binary file if anyone wants it. It is 
hardcoded to use a fixed filename and runs off of a standard DOS 6.2 or Win95 
system-formatted floppy. It can be easily modified by anyone with NASM.

Finally, has anyone translated colorForth source to NASM syntax? I don't have 
any MASM references and don't understand stuff like @@b: as a label in 
Chuck's source (for starters).

Myron Plichota
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com