Wow, I am glad it works on PAL systems.  Thanks for the report abraXxl.

Quote from: abraXxl
Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

First time I've heard of anything like that.  I never owned a 1581, and haven't seen a datasette in years (me and my friends are still wondering what happened to the one we had years ago...).  I was only able to test that it works with 1571(s) attached (in 1571 and/or 1541 mode).

I never even thought to try C64 mode... well, actually I had to use C64 mode for loading with a defective fast serial version... but once I got fast serial working, I totally forgot to try C64 mode again.  Anyway, it would not matter because I don't have a datasette to test with.

If anybody knows more about the C64 / 1581 bug, then it might be possible (from that info) to fix the firmware...

I don't understand the UART dump... but I do know I had problems like you described at one point, and it was a similar problem.  Whenever there is a "disk change", either by insert new memory card, or "disk swap" button, or "CD" into disk image, then the firmware is coded to act like a 1571 and set "disk ID mismatch" until a BCIS "log in" occurs.

The "log in" can be with BCIS command "Inquire Disk" or "Query Status" as I recall... I don't have the code in front of me to tell you which U0 commands these are (I'm thinking code $0c is one).

Anyway, I had the problem described, where you get "booting cp/m plus" - "read error - hit return to retry".  This was fixed (for me) by changing firmware to clear the "disk change" when either BCIS command described above was sent.  So I could do this...

OPEN 1,10,15: REM uIEC default unit 10
PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk image
PRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8
CLOSE 1
BOOT

Umm... maybe I attached the disk image after changing the device number, but I don't think it would matter.  Anyway, CP/M worked for me, so I don't know the problem.... as I recall, the CP/M boot process will send the BCIS $0c command before any read sector commands, and it will also send it again after CP/M system is loaded but just before the A> prompt appears (I'm guessing this is just before CCP.COM is loaded).  Also the BCIS $0c command has high bit flags, and as I recall the actuall code sent is $4c (i.e., $55 $30 $4C $00).

I guess I can take a look and see if there is some obvious problem... BTW, I have no idea what HEAD is... can somebody explain?

I sent Ingo an email, so maybe fast serial will get integrated into the main line firmware...

If you haven't fixed that PSU already, it would be nice if you could post a photo of the screen with the bars.  I have an idea would it would look like, but it could be informative for people with a defective C128... and they say "a picture is worth a thousand words."

Anyway, like the others said: your English is actually very good and welcome to the forums!

Wow, that is really strange that using an odd number messes up interlace on PAL.  I'd have to play with my C128 again to be sure, but as I recall, my NTSC did need an odd number in register 5.

In fact, since the same chip (8563) is used for both NTSC and PAL (unlike VIC which has different chips), I am quite confused...

Quote from: tokraAlso, why didn't they set register 0 to 127 leading to a very neat 15.625 kHz raster rate (exact PAL). Maybe there is a correlation between the higher raster rate of 15.748 kHz and the 640 lines...? Any idea?

Wow, I always assumed both standards used 15.75 kHz raster rate... thanks for the info about PAL.  I wouldn't think there would be a correlation between horizontal size and number of rasters, but I guess it is possible.  After all, this thread started because interlace didn't work for me when using the "correct" horizontal size, at least not until the change to the DRAM refresh rate.

It seems after 9 revisions, the VDC still has bugs...

I take it that C128 forum disks #1 and #2 are the actual software used to manage this site?  And since some of it won't run in VICE, that means a real C128... I guess that would explain the "High Server Load Messages"... the poor little 8-bit has too much work to do 

Ooh, I missed the mega-upload.  Now that you posted it, I remember seeing it... PARITY ERROR.  Thanks, I'll give that a look!

No I haven't.  Thanks for the link.  Man, that guy has got the color down pat!  I don't see how the VIC can do that... gonna have to take a peek...

As I understand it requires a 1541 Ultimate which can transfer data at REU-like speeds... quite a bit more than a 1581, CMD-HD, or uIEC can cope with... on the other hand, wuz up with the audio?  If you got that much bandwidth, why wouldn't you have 4-bit (or 8-bit) audio samples... guess all (well most) of the bandwidth is going to the VIC...

But still don't see how the VIC is doing the color... sprites under bitmap? urrr... this is gonna bug me till I find out.

Edit
Trying to find out more about this software, I search on CSdB for 'nuvieplayer' and #118874, but get "We're terribly sorry" message.  Really strange that links through CSdB can't be found; maybe because it is hosted on sourceforge ?  But still... bad index, very bad, bad index...

Edit 2
The link above takes you to possibly related Java SID player... but searching there turned up nothing about the nuvie player...  is this a case of vaporware ?  I did download the 'player' from lemon, but without any media files (or a 1541U), I dunno how useful it will be...

Edit 3
Returning to CSdB, a search for "video player" also turned up 0 results.  Me thinks their search no worky... I mean there has gotta be a video player of some sort for C64 right?

Sing along if you know the words:

Quote from: Aerosmith
There's someting wrong with the world today
The lightbulb's gettin' dimmed
There's meltdown in the sky

Dude, that sounds awesome!  Mainly because you used the magic word, "sprite".  Most video controllers nowadays have no concept... they want you to render everything with software...

I LOVE IT!!!!          It's not perfect, but if you don't like it, byte me!

Before I forget, thanks a lot for your posts Jim, very informative.

So some quick stats before I get to the boring details

Test	Format	Load--	Save
Standard (slow)	FAT	66.9s	51.7s
CP/M (slow)	D71	87.1s	...
CP/M (fast)	D71	11.9s	...
JiffyDOS	D81	6.03s	42.9s
JiffyDOS	FAT	6.00s	21.6s
Fast-serial	D81	5.12s	48.9s
Fast-serial	FAT	4.98s	27.5s

All the load / save times are from 142 block file on a uIEC connected to NTSC C128... the exeption is CP/M where I just timed the boot process (from BOOTING message until A> prompt).  I forgot to test the load/save on a D64/71/81 using slow serial... so sue me.

As you can see, the load times are about 20% faster when using fast-serial compared to JiffyDOS, and about 1240% faster (!) when compared to standard (slow) serial.  Also you may notice some weird things in the table... like standard serial will Save faster than Load!!  Also JiffyDOS will save about 28% faster than fast-serial (but it's the loading that counts, right?)  You can also see that load times are a tiny bit faster using the native (FAT) file system as opposed to a disk image (D64/D71/81), but the save times are about 2x faster on the native file system... hmmm...

If you're wondering why most of disk images are D81 except for the CP/M test, it is because there are two types of fast-serial... there is the normal fast-serial used by the KERNAL for LOAD/SAVE/VERIFY and then there are special "Burst Command Instruction Set" commands (BCIS) that are used by CP/M when it detects a capable device (1571, 1581, or likely CMD-HD).  The 1571 will use "native" sector sizes (256 bytes) and "native" block specifiers (start at Track 1, Sector 0).  But the 1581 (maybe CMD-HD) uses 512 byte sectors and "CHS" block specifiers (start Track 0, Sector 1).

Long story short, I don't have the time or motivation to implement the CHS system, so the BCIS commands that use cylinder/head/sector specifiers will fail, like on D81... also on DNP, but that is mainly because I don't have any DNP images for testing.

In other words, I took the extra time to make sure that CP/M would at least work with "standard" block specifiers, like on D64 and D71 disks.  Actually, I don't know why!  I'm not a big CP/M fan... it is more of a curiousity to me... like DOS or Win3.11...

The important thing, for most software in general and Media Player 128 in particular, is that burst-load works... it works fast... and it works with any type of disk image or the native file system. 

I've attached a binary that you can use to flash a uIEC.  It is a "prerelease" version which means you can replace it with any other version if you don't like it.  More importantly, it is based on older code (0.8.2) that does not have GEOS support and may not have support for DNP images ... if somebody has a DNP image to contribute, that would be nice!

Also attached are the source files so other people can fix everything I messed up!  This is my first experience with the AVR, so have a good laugh at my code.    If any of you are decent C and assembly programers, I recommend playing with it.  I learned a lot... mainly how much I still need to learn! 

This is one of those things somebody could spend months working on, but I gotta get back to Media Player 128... I just can't wait to see what happens!!!  I mean 20% improvement might not sound like much, but the raw transfer speed is not as important as the fact that (once data is known available), it can be "aquired" with 1 instruction (LDA $DC0C), as opposed to 16+ intructions required for JiffyDOS... AND there is no need to wait to avoid VIC bad lines... AND there is no need to use 1MHz... I'm pretty psyched, can you tell?

P.S.
My amount of testing has been fairly minimal.  Burst-load seems reliable after mutltiple tests, and that is the main reason (for MP128) for this side-quest.  In particular, I recommend you not use it for saving important data... at least not until you've had a chance to test it for yourself... I only had trouble with BCIS (CP/M type) saving, and it was quickly fixed... however the testing was very minor because, again, burst-load was most important to me.

I took the extra time to implement most of the BCIS instructions.  The only instruction not implemented is "burst format".  I had planned to simply change the command string into a normal "NEW/HEADER" command and pass it to the existing code, but there is no existing format code (at least not in this old version)...

I could go on and on, but will shut up for now and post a more complete write-up on my website... when I find the time from working on MP128 of course...

Quote from: brain
As the author of the $=P code, I'm glad you found it useful.  It took some time to make it work correctly.

Very useful, thank you!  In retrobution (word?), I took the time to be sure burst-load on the SD2IEC (uIEC) works with multiple partitions.  For example, CP2 (goto partition 2) but you can still burst-load from partition 1 with, for example, "1:filename" ... or vice-versa ...

Thanks for the info about NT7!  I'm still using WinME for my multi-part SD (to busy to fix my Linux partition).

Yes, Diddl, uIEC has support for SRQ.

Thanks for the links, abraXxl,  I am muddling my way through fast-serial alone for the moment (experience is the best teacher).  I'll be sure to check them out if I get stuck.

The problem (as previously reported), was I had not programmed the SD2IEC to send a proper "fast-serial acknowledge" because, then, the C128 would want to transmit fast-serial and I had not got far enough on the SD2IEC to accept fast-serial.  I hope that makes sense!

In other words, the first run was just SD2IEC transmitting and C128 receiving, and not the other way around... but the C128 KERNAL doesn't like a half-way job...

Anyway, I wanted to report that I implemented the "fast-serial acknowledge" and at first had trouble...

Everything worked fine in C64 mode (at least I didn't break slow serial), but in C128 mode, I could only read the error channel... could not send any commands or load any files... So that was one step back...

Some investigation revealed the C128 was indeed receiving "fast-serial acknowledge" but there was an error sending data from C128 to SD2IEC...

It turns out the standard Listen routines, even though re-coded to accept fast-serial, were still too slow.  So I went hard-core on the firmware (yea for bit-banging) and now the code is sending and receiving fast-serial.

So now all the standard commands are working again in C128 mode, but there is still a problem with the ever-important "burst load".  Remember I said COMMAND.COM was too big to fit in Bank 1?  Well I was wrong... it is only 54 kiByte.  There is a problem with the fast-load detecting end-of-file!

Almost there... should just be a minor detail to fix... then I can report some actual speeds and get back to Media Player 128.

P.S. I checked the assembly listing, and SRQ is definately input on bit 7 of port 0x3 and output on bit 7 of port 0xb... again this is for Atmega1281 / uIEC configuration; can't say about anything else...

I haven't posted any code yet.  Will do once I get the "fast serial acknowledge" fixed... until then, C128 users would have to GO64 in order to LOAD anything... or use my custom debug software which ignores this detail... either of which is NOT user friendly... more like user angry 

The SD2IEC sources already have SRQ defined.  There is IEC_OBIT_SRQ, which an actual bitmask for the IEC output port, and there is IEC_OPIN_SRQ which is the actual bit-number.  I checked the assembly listing after build, and noticed this comes out to $80 (bitmask) or 7 (bit-number) for I/O port 0x03 (input) or port 0x0b (output)... if memory serves correctly (the build was done on a different PC).  More importantly, this was built using the uIEC / Atmega1281 configuration, could easily be different for other devices. 

I wanted to report my progress with the SD2IEC firmware for fast-serial support.  The good news is that I only half-bricked my uIEC     Read below for details or try another thread if you're in a hurry (long post).

I got fast-serial output working with only a minimal amount of debugging.  Then I wanted to go to the next level and start implementing the Burst Command Instruction Set (BCIS).  These are the "U0" commands without friendly character interface.

Well the most popular command of the BCIS seems to be the "change utility", command $1e, which (because flags are ignored for this instruction) can be entered as $3e ... which leads to yea old favorite "U0>??" commands.

Even devices that do not support fast-serial or BCIS often support sub-commands of this function.  Such as...

   
• U0>(device#)
• U0>S(sector inteleave)
• U0>R(error retries)
• U0>Vn (verify off or on)
• U0>Mn (switch 1541/71 emulation)

But the $1e command is only one of several BCIS instructions.  Because my primary motivation is fast-serial loading for Media Player 128, I was really interested in the $1f command -- a.k.a. "burst load"

But the $1f command is one of the more complex instructions.  The only one more difficult would be "format disk" which takes many, many, parameters due to the MFM (a.k.a. "foreign CP/M") disk capabilities of the 1571 and 1581.

So the simplest BCIS command, which actually returns information (unlike U0>Rx for example, which only accepts data), would be $04, "Inquire Disk".  This command returns a single status byte using fast-serial protocol.

And yet this simplest of commands is something that Commodore managed to screw up.  On the 1571, this command will return $01 for "ok - GCR format" but it has a wrong sector size (bits 4,5)... if you were to interpret the value per these bits, you would think a standard 1541/1571 disk had 128 byte sectors... well I'm sure anyone who has read this far knows these 5.25 floppies have 256 byte sectors...

However, Commodore says the sector size (and other disk info) is invalid if bit 7 is clear ... meaning GCR / CBM format... Bit 7 is clear in the value $01 but...

If you execute "inquire disk" (command $04 remember) on a standard 1581 disk you get a value of $20, meaning "GCR / CBM format" with 512-byte sectors.  Well first, if it is GCR/CBM, then I don't see how it could be 512-byte sector... and second, considering 1581 really does use 512-byte sectors, it should also report MFM format (since that is reality)... that is, it should be honest and say $A0 (MFM 512) or lie and say $01 (GCR sector size implied) or maybe $10 (GCR 256 -- logical format).  We've all read the 1581 manual and know the difference between logical and physical formats right?  Thought so.

So anyway, the 1581 can't tell the truth and it can't tell a good lie either!  Well, there you have one way to distinguish a 1581 from other devices...

Faced with this conundrum, I just programmed the SD2IEC to report $01 like the 1571 since most software seems to come on 1571-compatible .D64 disk images.

Moving along, the next more complicated command (and very useful by the way), is command $00 or "Read Sectors".  This is the fast-serial equivalant of yea old favorite "U1" or yea old hated "B-R" commands.

This works well enough with a 1571.  But when you try it on a 1581... incompatibilities again... thanks Commodore!  That was sarcasm.

On a 1581, the same instruction seems to do "physical-to-logical" or maybe "logical-to-physical" conversion.  I'm not sure which... here is what I know...

On a 1571, if you tell it to read track 1, sector 0 (every C128 fan's favorite boot sector), then you really get the boot sector.  Nice.

On a 1581, if you issue the same command, you get an error because the 1581 doesn't like sectors numbered 0.  So if you change the command to read track 1, sector 1, then you get... track 2 sector 0!!!  This is because the 1581, being MFM based, starts numbering tracks at 0 instead of 1... and numbering sectors at 1 instead of 0 (but remember it does NOT report MFM when you "Inquire Disk").

So now the 1581 is pissing me off.  Anyway, I programmed the SD2IEC firmware to act like a 1571 and give you the boot sector when you ask for track 1 sector 0.  How hard was that?  Not hard for me... too difficult a concept for CBM appearantly...

[Disclaimer]
I have 2 1571s in addition to my uIEC.  One 1571 has original CBM ROM and the other has JiffyDOS.  I do not have a 1581.  The 1581 testing was done using VICE.  So it is possible the problem is with VICE or is completely my fault.
[/Disclaimer]

Moving along... so we got single byte fast-serial working (Inquire Disk) and we got entire sector (256 byte/command) or even multiple sectors (but only on the same track).  Next we have command $1f, "Burst Load".  This takes an actual file name (which thankfully the 1581 doesn't screw up) and loads multiple sectors anywhere on the disk... sweet!

Now there are several devices that use the SD2IEC firmware, but I only have a uIEC to test with.  (I recommend it by the way.)  When you issue a Directory command, the funny thing about the device is that it lists the file size in terms of FAT clusters... definately not the same (often MUCH larger) than a standard CBM "block"...

Anyway, the first file I decided to "burst load" was one that appeared in the directory as 240 blocks or so (don't know the exact value).  Now if these were normal GCR / 256-byte blocks, it would all load in Bank 1 (where I load stuff for testing).

So I burst-load "COMMAND.COM" in my first test (the DOS 6.22 version, because I'm a dork) and am initially pleased to see that it starts loading without error, but then am I bit suprised and disappointed when my computer crashes...

Because the file size was in clusters (I'm guessing about 2048 bytes) instead of normal 256-blocks, the file was WAY WAY too large to fit in Bank 1, and thus (due to my hasty programming), trashed the MMU and/or CPU vectors in the $FF00 region of memory...

So after a 0.5 second reboot (beat that Micosoft!), I was quite pleased to find that COMMAND.COM loaded successfully into RAM Bank 1 (well, up until $FF00).

Having said all that, let me back up a bit and say that everything had been working fine.  In particular: LOAD, SAVE, VERIFY, and SCRATCH.  I saved my slightly modded C128 code from the ML Monitor (the code I was using to test the BCIS / fast-serial) without trouble.  But when I tried to VERIFY, I got an error...

Naturally this was quite disturbing... I was able to list directories, save, and scratch files... but would get I/O ERROR #5 (device not present) whenever I tried to load or verify a file...

To save you more boring details, let's just say I discovered load/verify does work correctly... in C64 mode...

So it seems the C128 is trying to issue "burst-load" (or verify) to my uIEC, even though I have not yet programmed it respond with "fast-serial support"... that is one of those JiffyDOS-like protocol changes that occurs inbetween serial commands (in this case, when the KERNAL pull ATN low, but before it sends the device address in a TALK/LISTEN command).

To summarize, 3 new BCIS commands are working using fast-serial protocol (in addition to the previous commands that did not require fast-serial).  But the "burst-load" only works when issued from my debug software and causes "device not present" error when standard BASIC / KERNAL commands are used.

So I just need to add the proper "fast serial acknowledge" to the firmware, and it should work fine with KERNAL / BASIC.  I would also like to get a few more BCIS instructions working so I can test it with CP/M.  CP/M is the most disk-intensive software I can think of, except for GEOS.  But it doesn't count because it uses custom software drivers.

Oh yeah, I wanted to report about the speed.  Sorry I don't have any exact numbers for you yet, but it is fast... REALLY FAST.  Okay, it is not REU fast or anything, but it is faster than 1581 JiffyDOS... if that means anything to you!

Wow, go to work on firmware and you miss all kinds of things!  So,

A.  Happy Birthaday Robert!
B.  Thanks for the link, Lance.  I only had IE3 for Win3.11 until now... can't wait to try IE5.01... Seriously! ...it took a while to get Win3.11 actually running on my new PC, so this sounds like a good test!
C. The new forum software seems to be running fine for me and I'm still using IE... let me check... v8.0.6... funny thing is sometimes I get a pop-up that says "High server load detected."  Umm... I'm guessing this is some sort of excuse for slow loading?  But pages seem to load the same speed weather or not the message is present...
D. Really sad you have to implement such strict measures for new members, Lance.  But if you do like BDD says, then be sure to automatically accept everyone who tests positive!

Glad the ASCII/DIN tips helped.  I can't help much with VDC, unless you need 16kRAM testing.  I have original 128 with only 16k VRAM.  I bought some 64K chips over a year ago, but still haven't found the time to install them... busy, busy, busy!

That is too funny

Weird doesn't begin to describe it!  I'm glad I don't live in Italy... those 3 minute commercials would kill me.

Anyway, besides the weird dancing women stripping the guy, I found it amusing it kept showing scenes of video games, video games, video games, and he was mostly using keyboard, keyboard, keyboard... every now and then, touch the joystick...

Like I said, too funny!  Thanks for sharing.

And I thought I had a lot of free time on my hands...

But even considering the signifcant fact the guy's instruments were limited to disk drives, he still does a better job than me... my SID music makes an Atari 2600 sound good...

Airship... can't wait to hear your symphony!  Maybe you could do the Commodore theme?  Something by Bach if memory serves... *PARITY ERROR*

You got it right.  They bend the standards.  For example, the popular ZED text editor (very nice, in my opinion) also bends the standards.  According to the author, he just tried different VDC values until he got something that "looked good".  Commodore monitors, in fact most CRTs, are quite flexible in the vertical department.  They tend to be a bit more picky for the horizontal frequencies, but there is still some slack.

These "sloppy" standards cause most of the problems people report when trying to use an LCD display, in my opinion.  I'm not saying that sloppy values are good, but I do think it is amusing that futuristic (modern) equipment lacks the ability to sync to a variety of frequencies like the archaic (vintage) equipment.

The thing that always confused me (still does) is the VDC registers are sometimes X-1, sometimes X, and other times X+1... and the documentation is not always clear as to which "flavor" a particular register requires.  So I guess experimentation was necessary.  Anyway, have fun tweaking!

Thanks for the feedback!  Nice to hear it works on real PAL.  Video on the VDC would be a neat trick.  With JiffyDOS, you still could not have full 2MHz capability, but you would still have a lot more CPU speed than with VIC.  I don't think that would compensate for the slow VDC RAM access, but it would be interesting to try...

Note that JiffyDOS was just an easy way for me to test the concept.  Well, maybe not easy (look at the source code, it's a nightmare).  Anyway, I'm working on fast serial routines which should help the frame rate a bit...

It sounds like you are on the right track... if you store $80 into $ac5 (BANK 0: POKE 2757, 128), then the KERNAL will not clobber VDC RAM with character updates.

As for the VIC, you have discovered that you can POKE the font you want, but the user can over-ride by pressing ASCII/DIN.  This is because you, as programmer, can only force the value to 0v.  You can not force the voltage to +5v.  So if you poke to get the +5v (standard character set), the user always can press ASCII/DIN and force it back to 0v.  The only sure way to prevent this, is to open the computer and disconnect the ASCII/DIN line from the CHAR ROM.

But this is only a problem for VIC if you use ROM for characters.  You can load your own charset into RAM, and tell VIC to use that... then ASCII/DIN will not change the VIC font.

For example, if you copy a font to RAM at $2000~$27FF and you want the VIC text at standard location ($400), then you can try this:

BANK 15 : REM JUST IN CASE
POKE 217,4 : REM DISABLE CHAR ROM IN TEXT MODE
POKE 2604, 24: REM TEXT AT $400, FONT AT $2000

For more info, consult C128 Programmers Reference Guide or Mapping the C128 and lookup locations $D9 and $A2C.

Good luck!

Gee, Mirkosoft...  I don't know what you are smoking, but I do wish you would share 

You can make up "software" video modes all day long... but you can NOT make up "hardware" modes.  You can not make the VDC display 4 colors using bit pairs 00, 01, 10, 11.  You would have to replace the VDC with another chip.

You can emulate 256 color VDC using color dithering.  Bit 0 one of 16, bit 1 one of 16 = 16 * 16 = 256... but it is still just single bits... 0 or 1...

Maybe that is what you mean, and I just don't understand.

The nice thing about the VDC is you don't have to use 8x8 cells.  For example, you could have 8x2 cells (8 pixels wide, and 2 rasters tall).  Of course the smaller you make the cells, the more attribute memory you will to cover the entire screen.  You need 2000 bytes to cover 640x200 bitmap with standard 8x8 cells.  If you use 8x4 cells, then you need 4000 bytes of attribute memory.  With 8x2 cells, you need 8000 bytes.

Reading your post again... maybe you want 4x8 cells ?  That would require 4000 bytes of color memory for standard 640x200 bitmap... and you could have 4 colors in the 8x8 "software" cell... but still only 2 colors in each 4x8 "hardware" cell...

I think it would work very well.  Somebody with a SuperCPU could probably tell you for sure.  It sounds like the same concept to me, from what I know.  Of course the SuperCPU is a bit hard to come by and rather expense when it pops up, so if he has something new in mind, that would be great.

Quote from: BlacklordFortunately we're reasonably lucky here - we can do an online one that does things likes pre-populates details from group certificates, Medicare rebates etc.

Makes it relatively quick and easy.

Sounds sweet.  We can file online, but have to use an agency (no direct submissions).  I guess the IRS computers aren't very secure... or stable... or they just want to make somebody else to take responsibility... or they want to boost the economy by creating new jobs...

Quote from: RobertBThe computer is the best, but what tax program is he using?

Good question!  Knowing him, it's probably ICE-PIC.

I got one of my tax forms completed and sent in last month.  Unfortunately I still have to file state and federal income tax returns.

I normally do my own returns, but would really like to spend my time working on uIEC firmware.  So I sought out some professional help.

I recommend this guy, he's really cool.  I am confident I will get the maximum legal refund because he uses the best computer equipment (see photo).

He guarnantees his work 100%.  The only thing that worries me is that he won't be around when / if I get audited.  Anyway, if you're interested in tax help, you can call 1-800-4-FROSTY.

No, but thanks for the link!  I just downloaded the latest SD2IEC source, as the one I had been working with is a few years old.  Older is usually simpler.  KISS.

Anyway, many new docs by Ingo Korb.  Really good read if your into disk drive codes.  Interesting to see other peoples take on stuff like Epyx and GEOS fastloader and copy protection.  I believe he received the bounty for the GEOS implementation.

I don't think I would have got very heavy into ML programming or into controller programming at all, if it were not for those pesky copy protection schemes that always begged me to break them.  See there is some good in copy protection

Quote from: BigDumbDinosaur As all NT filesystems are either 32 or 64 bits, there's no reason to use extended DOS partitions.

Unless you want (or the Billy-ware requires) each OS to have a seperate partition.  The MBR only supports 4 partitions, so if you want more (for me, over a dozen) then you are required to used extended partitions.

More importantly, there are only 2 (primary) partitions on this test card, all listed in the MBR.  So extended partitions aren't really relevavent.

I was curious to test the limits of the uIEC firmware which seems to be designed to handle at least 16 partitions, but if I added all 16 (and they actually showed up in Windows) then the total number (on my PC) would exceed 26 ... error!

Ummm... maybe you are referring to memory cards in general and I am thinking of my HD in particular?  Well going back to memory cards, the two 2GB cards I have are formatted with FAT16, and the one 32MB card I have is formatted as FAT12 (to my surprise).  In other words, none of them use 32 bit nor 64 bit file systems; they are all DOS-type file systems; I have never seen a memory card in NTFS format, although I don't see why it couldn't be done...

Edit

Quote from: BDDAlso, recall that until Windows 95 OSR2, there was no 32 bit filesystem support (FAT32) in the DOS derivatives

That reminds me, I have found an NTFS driver (read-only) that I can use in DOS mode, or more importantly Windows 3.11, but I have yet to find a FAT32 driver for DOS 6.22.  I guess I could re-configure my Win3.11 partition to run under DOS 7.1, but would prefer to leave it as DOS 6 for historical reasons...

This is going a bit off topic... ooops!
/Edit