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.

Having completed phase 3 of Media Player 128, the JiffyDOS "Proof of Concept" (or mis-concept, depending on your opinion of low video frame rates!), I now move onto phase 4, which is implementing fast-serial protocol in the SD2IEC firmware...

I only have a uIEC/SD to test this with, but as I understand the same firmware is used with MMC2IEC... also my main reason for this effort is for much improved Media Player performance, but it should benefit the C128 community in general... in particular CP/M should be possible at "fast" 1571/81 speeds instead of the pathetic 1541 speeds...

So I first went to the source and got SD2IEC firmware.  Next, for the Atmel compilation, I went to the vendor.  Unfortunately, the "C Tool Chain" (as they call it) only works on Win NT and not Win 9X....

Really bizarre if you ask me!  I see no reason why I can't compile source code with DOS (or CP/M if I wanted to do so)... well if the vendor sucks, go to the open-source community!  WinAVR was my next option and it runs fine on both Win 9X and Win NT.... (see notes below)

One important thing to note is that if you use Win 9X (95/98/ME) that you need to edit the Makefile around line 230 and change

WINSHELL = CMD

to

WINSHELL = COMMAND

Another important thing is that neither WinAVR nor the uIEC source code includes "CRCGEN-NEW" binary.  This is critical for updating the firmware of the uIEC (maybe MMC2IEC also).  It appends a CRC checksum to the binary so the firmware will accept and update the EEPROM.  I found a copy here, but haven't tested it yet.  (The last link seems to be the official SD2IEC "site")

Also strange about WinAVR is it seems to (re)install a complete POSIX-style build environment.  I have been using Cygwin and MySys for several years now to build Unix / Linux style binaries for Windows, so don't really see why I'd need to install another copy of cygwin.dll and all the other binaries... 

Anyway, an important thing to note about the WinAVR installer is that it semi-assumes your OS is installed on drive C.  If it is not installed on drive C, it will set AUTOEXEC.BAT on drive D (or other non-C drive) but Windows will only read AUTOEXEC.BAT from the boot drive (thus the drive D file is ignored).

I've come to expect this behavior with my hexadeci-boot system, but thought it would important to mention for others without the benefit of experience.

Anyway, I just thought toss out my experiences thus far and ask for any/all opinions regarding firmware builds for uIEC / MMC before I brick my own hardware... thanks!

About the code... if the above isn't clear, let me state it plainly... I'm working on the code but haven't tested it yet.  Right now I have uIEC to output fast-serial using a "rigid" software loop like used with JiffyDOS / Final Cartridge 3.  This isn't the optimal way and does not support fast-serial input yet... that would require re-configuring the hardware... not something I'm up to yet...

The #1 priority is to implement Burst-Load (for MP 128) but would also like to implement Inquire Disk, Log Disk, Sector Read, and Sector Write (for CP/M etc.).  So like I said, the code is coming along, but would like some feedback before trying to burn my device...

I wasn't quite sure where to put this thread, but this is where it ended up!

In preperation for mod the uIEC firmware, I was checking the source code and noticed the provision for multiple disks on the same memory card... via the Master Boot Record found on IBM PCs (nowadays mostly Windows or Linux).

All of my SD cards (all 3 mind you) only have a single FAT file system.  But in an effort to test the firmware of uIEC, I decided I would like to setup multiple partitions on a memory card to see what happens... So I opened up the SD card with a sector editor, expecting to see a single floppy-disk-style FAT boot sector, but...

To my surprise I found an hard-disk-style MBR boot record.  Really strange because if you open "Disk Management" from Windows' "Computer Managment" the partition commands are grayed out (using Windows 2K or XP).  The Master Boot Record only had 1 partition, corresponding to the single FAT drive...

Okay, so MS doesn't want to let me create extra partitions, but the memory card seems to be set up to handle them, and the uIEC firmware is definately coded to handle them... so I decided to make some more...

Using a sector editor, I modified the MBR to have a second partion.  I also modified the boot record of the first partion to be smaller and added a second boot record for the remainder of the memory card.

Now creating boot records by hand is a bit risky so I wanted to run "ScanDisk" to be sure I hadn't fouled up anything... and that is where it gets interesting...

On Windows 2000, the memcard shows 2 partitions in "Disk Managment" but only the first one gets a drive letter (and thus the second is "invisible").  When I click the option "Add drive letter/path" and set an appropriate value, the system gives me an hour glass (please wait I can only do 1 billion things per second)... and then after waiting a few seconds I get a message "Please restart the computer to access the extra drive".

Ummm... that's something I would expect from Windows 98/ME... but okay here goes...

Several seconds later Win2K is back up, but the 2nd partition still isn't listed.  So I go back to Disk Management.  It still shows 2 partitions with only the first having a drive letter.  So I try again to assign a drive letter to the second partition and the same thing happens: hourglass (wait a few seconds) then message (please reboot).

Okay, so maybe Win2K drivers are out-of-date (it is 2011 by now), so lets give WinXP a try... Long story short: WinXP does the same crap... I don't have (an intend NEVER to have) WinVISTA.  Still debating Win7...

So you would think (I surely thought) that there was something screwed up with the MBR or 2nd partition boot record that I manually created... but...

Operating system #4 and #9 to the rescue!

If I boot Windows ME or Win98, then both drives show up just fine!  I run scan disk... no errors... I copy files to each partition on memory card... no errors...

The funny thing, IMHO, is that older Win9X (notorious for reboots) did not ask me to reboot and it worked... unlike the newer NT systems (promoted for fewer reboots) which told me to reboot but still failed... what a bunch of junk...

But this isn't a post to bash Microsoft, anybody can do that anywhere, anytime   The important thing is what happens when I stick that memory card into the uIEC and access it with a Commodore!

Good news!  Both partitions show up with $=P, I can change to either partition with CP, and the files I copied (using Win ME), all show up.

So Commodore firmware beats Windows XP...  If anyone would care to report about multiple SD partitions using Win 7, I'd love to know...

Edit
For anybody who still has access to Win ME or Win 98 SE, the extra partitions seem like a good way to hide data from lame Win7 hackers... I imagine it would show up fine with Linux' Mount, but I fouled up my Linux system a few years back and haven't fixed it yet...
/Edit

I just noticed BDD now has an avatar.  These are always nice for quick visual recognition (as if the long name wasn't a clue).  However, after a closer look, it seems to be an image of a gorilla or other primate... that's not a dinosaur

This isn't a type-in program, it's a complete original work (which was probably inspired by some type-in program).  It is C128 BASIC program ("3d tic tac toe") with a sprite file ("xo3dttt")

One or two players.  For one player, I recommend using a joystick in port#2.  For two players, you can share the joystick or one of you can use the numeric keypad (0 acts like the fire button, other numbers as directions).

If you've never heard of this game, the idea is to get 4 marks in a row on the grid.  The marks can be horizontal, vertical, depthinal (that's not a word) or diagonal.  Player 1 has "X" marks and player 2 has "O" marks.

In one-player mode, you can choose from 4 difficulty settings.  You always go first (as X).  The screen will blank (2MHz mode) while the computer thinks of its next move.  This takes several seconds at the start of the game (when there are many empty spots to consider), but gets faster as the game progresses.  On the higher difficulty levels, you should probably spend more time than the computer planning your next move... at least I did... not that it helped, as you can see from the screen shot (the computer won).

Much more challenging than traditional (2D) tic tac toe, but a lot easier than chess.

Here is another type-in program I found.  This one is like Star Raiders.  I am assuming it came from Run magazine... anyway, it is quite a bit for a type-in consisting of 2 seperate files, a BASIC program ("star trip v1.1"), and an ML program that generates the star field ("startrip.o").

The "v1.1" label makes me think some changes were made, but they are probably pretty minor.  No obscene language

The idea is to simply find and destroy all the enemies before time runs out.  Use a joystick in port#2.  Left and right to stear, up and down to change speed, and the button fires your laser.  Unlike the real Star Raiders, this one doesn't feature a sector map.  (At least I don't think it does)

RobertB recently mentioned Tron in a quite unrelated post.  In particular, why there was no official Tron game for the C64/128.

That made me remember I had one of those type-in programs from back in the day that is very much like the motorcycle part of the Tron arcade game.

I appearantly no longer have the original type-in program; I do have 2 versions that me and some friends re-wrote.   Both of them use the joystick for input (except to start the game or continue).  If you look through the code, you will see where the original type-in was designed for keyboard input.  Well that's the main reason we re-wrote it -- we wanted to use the joystick.  Then we (or perhaps me alone) made a second version to allow for two player game.

The first (you versus computer), use a joystick in port#2.

The second (you versus friend), each plug in a joystick.

Warnings:
1. Obscene language for no reason other than we were young and found it funny
2. Each messes with STOP key vector, so after ending the program, the STOP key doesn't work... better reset...

You can't call yourself a true fan unless you drive a Holden VC Commodore.
 

Manufactured in Australia around the height of CBM's popularity (mid-early 1980s).  I imagine Lance drives one

Isn't the universe great?  After researching correct spelling of Lithuania on Wikipedia, I hit "Random Article" and got the closely related article Holden VH Commodore

Warning: long-winded post

I was playing around with videos on my Windows PC trying different formats / codecs that would work with anything.  Well it seems plain old MPEG(1) will work with anything (even Windows 3.11), but it does not have very good compression or quality (maybe bad encoding software).  Anyway, I came to the conclusion that MPEG-2 (.VOB files) should work with Mac, Windows, and Linux.  Unfortunately, I don't think they would work on iPhone or PSP.  Now MP4s will work on those portabile devices but they're not supported on Windows (at least not on standard Windows Media Player).  I downloaded a program called Media Player Classic that works on Win XP and 2K but not on 95/98/ME.  So I'm sticking with .VOBs for the moment.  (that means I need to find an MPEG2 player for Win 3.11)

ANYWAY

This got me to thinking back about playing digital audio (see this thread) on my Commodore.  I mean, I have several multi-gigabyte SD cards, but all my Commie software will only fill up half of one.  It just pains me to see all that storage potential go to waste

All this thinking made want an MP4 player for my Commodore.  So like a real hacker / moron, I started writing one.  After a day or two of coding I thought to myself, somebody has already done this... I just need to check out CSdb.  But then I thought, I might end up stealing someone's code so I better finish what I started and then compare.

So after finishing the testing of v0.9 of my software, I spent a few hours searching CSdb for things like "digi player" "video player" and "media player" and came to the conclusion there is no comparison!  By the way, search for "media player" returned 0 results.  I found that surprising considering over 400 results for "digi".  Completely off-topic, I also found a demo "Edge of Disgrace" which is totally awesome.

On topic, a lot of the "digi" software were demos.  There were some tools for creating / playing / editing digis, but none of them came with data files!  So I've downloaded several players but have nothing to play with them.  It's kinda of hard to compare.

Of course there were plenty of SID players too, and finding media files for them is no problem.  However, I'm not interested in those, as they are like CBM-specific MIDI files (is there a cool name like PETSCII to describe them?)

Most of the digi players / editors I found play 4-bit audio by banging SID's volume register.  Is there a common filename / type for these kind of files?  Like, according to the thread mentioned above, the Digimaster has DFF files, but these are 8-bit audio files.

I did find the ModPlayer which play's Amiga audio files.  I'm guessing these would be .MOD files?  I really don't know much about them, so if anybody has some info / links that could be helpful.  Also I hear there are also Amiga .IFF files?  Again any info / links would be welcome.  I didn't see anything that would play .WAV files, although I probably just missed it/them.

Now let me say there is SOME comparison because the digi-players I did find work very similar to the method I use, which is not suprising considering (yes I took a peak at their code after I finished my version 0.9).  HOWEVER, all the players I found work by loading the data into RAM and then playing them.  Well that's great if you want to play a 10 or 20 or 30 second audio clip... but it will not work for playing a 3:30 minute song or 1:30:45 video.

Of course the idea is totally ludicrous when dealing with a 1541, but quite practical for a 1581, hard drive, or uIEC.  Well you couldn't fit a video on a 1581, but you could fit one or two songs.

What I have now is player that plays my custom (I haven't seen anything else like it) audio files at 15kb/s.  By the way a 1541 / 1571 can work, IF you use the exact sector interleave of 12 for tracks below the directory and 11 for tracks above.  But you only get about a minute of audio (or two for 1571).

Now a 1581 or uIEC should be able to handle double the bandwidth, that is 30kb/s.  This could be used for stereo audio (umm, did I mention the software is only playing mono right now).  I haven't tested this yet because I don't have a second SID in my C128.  I guess I could test it in VICE if somebody wanted me to.

Or the extra bandwidth could be used for video.  An idea I'm still playing with...  Or the extra bandwidth could be used for playing 8-bit digis (if I can figure out how Digimaster works).

So right now, it plays my custom audio format of psudo-2-bit audio.  This is combination of 1-bit PW modulation plus 4-bit Volume.  The 1-bit samples play at 8kHz while the volume is updated at 1/4 rate or 2kHz.

Now this format has several consequences.  The pros:

- uses 1/2 the data of traditional(?) 4-bit digis
- high frequencies can be filtered
- good dynamic range / bass

The cons:
- the high frequencies are 1-bit, and sound rough, even with filtering
- the low frequencies can't be filtered (like traditional 4-bit digis)

After listening to some of the 4-bit digis on the demo software (not actual file players) that I found, I think they sound a lot better than my psudo-2-bit digis (duh).  If I went with 4-bit digis, at 7.8kHz, that would mean no possibility for stereo or video... unless...

The audio sample rate was reduced to 5.23kHz.  You loose a lot (more) of the high frequencies this way.  But even so, the "cleaness" of 4-bit over psudo-2-bit makes this desirable.  I should probably just put an option in the player.  When run at 5.23kHz (at 4-bit/sample) I should get a data rate of 21kb/s with another 21kb/s to spare for stereo audio or video.  I say "should" because I have not tested it... but am fairly confident it would not work with 1541/1571.

What I have tested is the 7.8kHz psudo-2-bit audio in the following scenarios:

- real c128 with uIEC (no problem)
- real c128 with 1571 (only works with optimal sector interleave)
- VICE with 1581 (no problem)
- VICE with 1541 (same problem as 1571)

Oh yeah, this requires drive to have JiffyDOS.  I guess it could be programmed with a fastloader if no JiffyDOS, but since this is only possible (AFAIK) with Commodore floppy drives and they are rather useless (except maybe 1581) I haven't worked on that.

What?  You're still reading this?  Wow, you sure have patience!

Anyway, I just wanted to toss these ideas and questions out there and see what you folks think before I publish something foolish.

Here is something I thought of yesterday, this is gaming device that runs SNES games.  It has 320x240 resolution, an SD card slot, headphone jack and speakers.  Runs for about 7 hours after charging.  It has some CPU called Ingenic JZ4740 which runs at 400MHz.  I know VICE x128 will run fine without "true drive emulation" on a Pentium II at only 333 MHz


So maybe I could reprogram the device for C64 / C128 emulation... wouldn't that be cool?  Of course it would be a monumental undertaking, so if I could sell some for a small profit, it would be worth the effort... of yeah, it is also an MP3 player...


Of course for C128's 80-column mode, compression from 640 to 320 would be neccessary.  Since standard characters have lines of 2-pixel width, there should not be a problem for text applications, but graphic applications (like GEOS) would suffer distortion in 80-column mode... remember no problem with 40-columns.

Maybe I should consult Jeri Ellsworth... anyway, Thanks for voting!

If this already exists, I will feel really stupid... I see there is an attempt for C64 on GBA but the GBA doesn't have enough resolution.  See http://splam.emuhq.com/ ... or not... it seems they gave up!  At least the link doesn't work for me...

I also found about C64 emulator for Java-enabled mobile devices... try http://www.dcemu.co.uk/vbulletin/showthread.php?t=187192.  It seems pretty technical... I think the smart ones here might figure this out, but most consumers would want an easy, ready-to-go solution like my idea...

I also found you can pay $4.99 to download C64 emulator for iPhone.  I do not have an iPhone, so no good for me.  Also, I am not promoting the product... I have no idea if it is good or bad...
Here is another link for C64 emulator on iPhone... maybe the same software, I don't know...

I also found you can pay $34.95 for C64/Vic-20 emulator for Windows Mobile Smartphone.  Again, I do not own Windows Smartphone and do not endorse the product because I have never tried it... somebody shoot me when I endorse Windows products...

There seems to be some confusion with the 1540 "autoload" feature, so I thought I should clarify the issue.  Many of the posts I quote come from this thread.

Quote from: cbm-iiI believe the Commodore 128 was the first C= machine to support auto-booting from a disk...

The C128 was the first CBM computer that will auto-boot a file (AFIAK).  However, the C1540 (maybe 1541?) is a disk drive that will auto-boot.  This works very much like the poorly-documented "&" command...

On power-up (see /RESET vector $FFFC -> $EAA0), the 1540 (maybe 1541) will auto-load and -execute the first file on disk (filename "*") if both /CLK and /DATA are active (grounded to zero volts) when the device powers up.

Quote from: 1540 ROM (reset code)

Code Select Expand


.8:e780   AD 00 18   LDA $1800
.8:e783   AA         TAX
.8:e784   29 04      AND #$04
.8:e786   F0 F7      BEQ $E77F
;/CLK active, test /DATA
.8:e788   8A         TXA
.8:e789   29 01      AND #$01
.8:e78b   F0 F2      BEQ $E77F
;both /DATA and /CLK active
;wait until both inactive...
.8:e78d   58         CLI
.8:e78e   AD 00 18   LDA $1800
.8:e791   29 05      AND #$05
.8:e793   D0 F9      BNE $E78E
;both /DATA and /CLK inactive, boot file "*"
.8:e795   EE 78 02   INC $0278
.8:e798   EE 74 02   INC $0274
.8:e79b   A9 2A      LDA #$2A    ;*
.8:e79d   8D 00 02   STA $0200 ;set filename
.8:e7a0   4C A8 E7   JMP $E7A8 ;do & command on file *


This code also appears in the 1541 ROM that comes with VICE.  I no longer own a C1541 (destroyed many years ago), and I never owned a C1540 (although some friends had them back in the day)...  so this is all based on info I have available today... please correct all errors I make that conflict with reality!!!

Anyway, what happens if this "autoload" feature is activated, is it will perform the "&" command on the first disk file (filename "*").  The "&" command can be summarized as executing a special file.

The special file will have the following properties in each sector:

A. start address in C1540 device (low byte, high byte)
B. data byte count
C. data
D. checksum (ADC all bytes, with carry).

If the checksum is wrong for any sector, then device will generate error "50, RECORD NOT PRESENT, TT, SS".  If no file is found (or file is REL) then you get "39, SYNTAX ERROR, TT, SS"

Please remember this special feature will only activate if both /CLK and /DATA are active (grounded to zero volts) when the C1540 powers on... and once the device recognizes this special condition, it will wait for either /DATA or /CLK (or both) to become inactive (+5 volts) before it continues to load the file...

Here is the code

Quote from: 1540 ROM

Code Select Expand


;file loop
.8:e7d8   A9 00      LDA #$00 ;reset
.8:e7da   85 87      STA $87 ;checksum
.8:e7dc   20 39 E8   JSR $E839 ;get file data
.8:e7df   85 88      STA $88 ;save SA low
.8:e7e1   20 4B E8   JSR $E84B ;update checksum
.8:e7e4   20 39 E8   JSR $E839 ;get file data
.8:e7e7   85 89      STA $89 ;save SA high
.8:e7e9   20 4B E8   JSR $E84B ;update checksum
.8:e7ec   A5 86      LDA $86 ;test "first block"
.8:e7ee   F0 0A      BEQ $E7FA ;no, continue
.8:e7f0   A5 88      LDA $88 ;Start Address low
.8:e7f2   48         PHA
.8:e7f3   A5 89      LDA $89 ;Start Address high
.8:e7f5   48         PHA
.8:e7f6   A9 00      LDA #$00 ;flag "NOT first block"
.8:e7f8   85 86      STA $86
.8:e7fa   20 39 E8   JSR $E839 ;get file data
.8:e7fd   85 8A      STA $8A ;data length
.8:e7ff   20 4B E8   JSR $E84B ;update checksum
;loop over sector data
.8:e802   20 39 E8   JSR $E839 ;get file data
.8:e805   A0 00      LDY #$00
.8:e807   91 88      STA ($88),Y ;store data
.8:e809   20 4B E8   JSR $E84B ;update checksum
.8:e80c   A5 88      LDA $88 ;address low
.8:e80e   18         CLC
.8:e80f   69 01      ADC #$01
.8:e811   85 88      STA $88 ;new address low
.8:e813   90 02      BCC $E817
.8:e815   E6 89      INC $89 ;new address high
.8:e817   C6 8A      DEC $8A ;count data bytes
.8:e819   D0 E7      BNE $E802 ;more data, loop

.8:e81b   20 35 CA   JSR $CA35 ;get file data (checksum)
.8:e81e   A5 85      LDA $85 ;get data (again)
.8:e820   C5 87      CMP $87 ;test checksum
.8:e822   F0 08      BEQ $E82C ;okay
;checksum error
.8:e824   20 3E DE   JSR $DE3E
.8:e827   A9 50      LDA #$50 ;record not present
.8:e829   20 45 E6   JSR $E645 ;generate error message

.8:e82c   A5 F8      LDA $F8 ;file end?
.8:e82e   D0 A8      BNE $E7D8 ;no, loop

;file loaded okay, execute...
.8:e830   68         PLA ;get SA low
.8:e831   85 89      STA $89
.8:e833   68         PLA ;get SA high
.8:e834   85 88      STA $88
.8:e836   6C 88 00   JMP ($0088) ;execute code


Quote from: carlssonIt seems I am referring to this Denial thread in which it says a VIC-20 with +8K expansion memory or more will search for an USR file, load it to the 1540 RAM and execute it. This feature was removed on the 1541, so supposedly the commands the computer sends out are just intercepted by a 1541. It is true there doesn't seem to be any mechanical differences between the two, but then again perhaps a 1540 ROM only works in a long board 1541?

The "&" command requires a USR file.  The "autoload" feature will accept any filetype except "REL".  The "&" command does work on 1540, 1541, 1571, and probably 1570 and 1581 (I don't have the last two devices).  I don't know how 1540 ROM would work on a 1541 board, long or short... I think it would work okay but with VIC timing instead of C64/128 timing...

According to the link above by carlsson, the C1581 is very picky!  It must have name "COPYRIGHT CBM 86".

There are few threads that relate VDC RAM Upgrade, probably the most relevantly titled is here, but it is asking about problems with existing product.  (I was encouraged to start a new thread when I tried to reply to that topic).

I've recently acquired some 64K x 4 bit DRAMs, part# 41464-10 (date code 9447).  Although they are 18-pin DIPs, I wasn't really sure this was the right part number (I always thought they were 4464's), but a photo in a recent post confirms the part# 41464-08.

However the part# in photo ends with -08 which I'm thinking means 80ns response time, while mine ends with -10 which I'm thinking means 100ns response time.  Anybody care to guess if -10s will work?

With 16MHz dot clock of VDC, I'm thinking 2MHz cycle access (assuming 8pixels/char width) which should be 1/2MHz = 500ns access time.  Of course the DRAMs use multiplexed addressing so really divide by 2 for 250ns access time.  So I think the -10 chips (100ns) I got should work...

Now obviously I could buy one of those converter boards, but as I understand the RF shield / heat sink will no longer properly fit once installed in a flat C128 (which I have).  Plus doing things yourself is more fun!  Another reason for me is to be able to switch from 16K to 64K mode, for programming compatiblity testing (if that sounds crazy, you should see my PC which offers multi-boot of DOS 6.0, Windows 3.11, '95, NT4, '98, 2K, ME, and XP... no Vista, maybe Win 7 soon)

I've heard you can simply cut out the existing 4416's and replace with 41464's.  Can anyone confirm this?  I'm concerned because the motherboard might not have all the lines connected (save money on copper etching?)

Assuming the "cut and paste" method would work, I plan to use an alternate method.  I would like to piggy-back the 41464's onto the 4416's with exception of Vcc.  Then install a switch to power either the 16K DRAMS or the 64K DRAMS.  How does that sound?

This thread could go under sever topics / boards of C128 Alive! but I decided on this place.

What I want is software that I can download to my C128 or my C64 imposter (C128 in C64 mode) that will give me the fast speed of JiffyDOS when used with an appropriate device.

For example, I own a 1571 with JiffyDOS and I own a uIEC/SD, but my C128 does NOT have JiffyDOS ROMs.  I would like to take advantage of JiffyDOS speed with my uIEC/SD even though I do not have C128 JiffyDOS ROMs installed.

I have a LOT of experience with writting fast-loaders for both C64 and C128, so I can write software to take advantage of such devices, even if I don't have the ROMs installed on my C128.

But, does anyone know of existing Software JiffyDOS, on the PC side???

This is just so I'm not re-inventing the wheel.  I am perfectly capable or writing my own version if needed... I have a LOT of fast-loader experience for 1541/1571/1581/c64/c128...

BTW, I think this would be usefull to many people.  Those with 1541/71/81 with JiffyDOS or users of SD2IEC or uIEC, but not JiffyDOS in there C64/C128.

If such software does not exist, I will write both C64 and C128 versions.

Currently there a couple of active threads regarding multiplexing ROMs or other devices, like SRAM.

I've always thought that for C128 (maybe even CP/M) mode that the /GAME and /XROM lines of the MMU would be an excellent interfacing option.  AFAIK, these are normally only used with C64 cartridges and if either line is active (0 volts = active, explains / character before name) when you power-up, C64 mode is automatically selected.

So I'm thinking for C128-mode, both of these lines would be freely available for programing / hardware-expansion purposes.  Some have questioned my assumption.  That is healthy skeptisism, because it would very bad for the C128 to try to pull one of these lines low while an attached cartridge is trying to pull the same line high... or vice versa... either way you risk burning up a chip or two if they are fighting each other.

So my question for all you cartridge owners (I have zero) is:

Are there any C128-mode cartridges that use the /GAME or /XROM lines that hardware hackers should know about?

I just got a Video Byte from eBay.  In case of you haven't heard of this thing, it's a video digitizer for the C64/128 from around 1988.

Since it interfaces to high bandwidth video signals, I assumed it was a cartridge.  Wrong!  It plugs into the User Port 

I tried it out and it works pretty good (if you consider 160x200 image at 4-level grayscale good).  It takes about 2.5 seconds to capture a frame.  So you're video source better be very still or better have a good pause / freeze-frame.

It takes about a minute to save the frame to disk as a Koala file.  I am not using JiffyDOS, so that part could be improved.

Another suprise is how it captures the image.  I imaged it would capture 200 rasters sequentialy from top-to-bottom.  However, the thing captures video horizontally from left to right.

I would love to investigate this blast from the past some more, but I'm swamped in projects now.  If anybody has some insights into this gadget, or links they want to share, I would appreciate it!

I have on this PC, VICE 1.22.0.0, which does not support copy and paste to the display screen.

So I went to the VICE Homepage, but they have an older version, 1.21. ()

I swear I remember downloading and using a version that supported copy and paste, because it was the bomb!  So I'm thinking that version must be greater than 1.22.

VICE 1.23 perhaps?  Does anybody know what is up with VICE?  I clearly remeber there being a new menu "Edit" which featured (at least) "Copy" and "Paste".

Last weekend I was testing my RGBI to S-Video converter to see what it could do, but it went wacky in interlace mode.  So I tried plain monochorme and it was still wacked.  I tried doing other stuff not using interlace (and using monochrome to avoid possible conversion issues), but still got some wacked out results.

I think my VDC is defective!

Can somebody tell me if this is the right code to set interlace on NTSC VDC?


W=DEC("CDCC"):BANK15
SYSW,64,4:SYSW,50,6:SYSW,56,7:SYSW,3,8


When I do this, the top half becomes a "squashed" vervision of the text and the bottom half becomes garbage, as expected for interlace mode without a 50-line editor active.

BUT, in the top half, the characters are staggered (rightward) like it is trying to output 84 characters per row.

If I change horizontal displayed to 77, I get as expected, staggered output (leftward).  If change to 79 displayed, it is almost normal (staggered one char per line).  But if I go up to 80, it is not normal, there is a large jump in staggering (rightward).

Okay, I thought, for some reason it doesn't like 80 characters/row interlace mode.

I changed horizontal total to 79 and got the slight (leftward) stagger of characters.  Then to make it look pretty (not staggered), I changed the address/row increment (register 27) to one.  Did this make a pretty picture?  No, it went bonkers again!

So then I thought, fork interlace mode, let's try something else.

There is quite a lot of unused border on both left and right of my screen.  I tried different row widths (horizontal displayed).  I can get 90 characters on screen horizontally.

But for some values, VDC goes bonkers.  Like with 83 characters, some characters "dissappear" for no reason.  At another value, I think 85, some of the characters would repeat.  At higher values, like 88 to 90, the VDC would both miss characters and repeat characters.

There seemed to be no pattern to what characters would vanish or be repeated (not a specific char from the font, or regular repeating of characters).

My VDC is just spitting out crud.  I think it's defective!  I can get a screen shot if anybody thinks that would help.

BTW, I haven't dissassembled my "new" C128 yet, so I don't know what Rev. the chip is.  While I was posting this, I just thought that I could PEEK $D600 to find out.

Is the uIEC still available or is the sd2iec all that's available now?

I couldn't find uIEC when I searched Jim Brain's site, but later found several photos on his site, including uIEC 3.0... searching here under "herdware" but only found RobertB's comments / observations.

It seems that sd2iec is available from NKC electronics.  Are they reliable?  Other sources of this promising device?

Were I to order from NKC, it seems I would need the sd2iec and daughter board kit.  Total of about $65 plus shipping.  Very reasonable I think for a compact, mass storage device.

Besides RobertB's observations, does anyone else have some experiences they want to share?

Aside from the practical uses, I'm intruiged about the possibilities.  The firmware is open source and there seems to be a lot of missing features to play with.  Like burst mode and d71, d81, and x71 support.

X71 is a custom format I made for use with VICE that allows other system's CP/M software to be used in C128's CP/M mode.  I remember downloading several games and applications from Atari and Tandy vintage computer sites.  The disk images were in (M)FM format which C128's CP/M mode can run using a 1571 (in reality or emulated with my custom format and patches to VICE).

I don't know how much free firmware is available or how much firmware my ideas would require.  Plus I'd have to learn programming for ATmega644... I probably don't have time for all that but just thought I'd ask for opinions...

Edit
Corrected typos
/Edit