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

Yeah, thanks for sharing!  The C64 looked really good in the line up... the Spectrum looked good but had no sound... the 2600 looked crappy but man if you ever tried to program that thing you would realize how amazing that software is!!

Now if somebody would just do a C128 version with sound clips like the arcade...

Thanks for keeping us up to speed.  I was pleasantly suprised to see "RGBI to S-Video" on the cover, along with some credit in the article.  If you look at VICE credits, you won't find my name associated with 2MHz code... *sigh*

Also in the issue is an article with programmer of Shoot 'em Up Construction Kit... one of my favorites!!  Of course it has its limitations, but it is a great way to "brainstorm" ideas.  Similar to the way I use Visual Basic for quick testing and then get down to C when the concept is ready to be "fleshed out".

Also there is mention of CBM-Command V2.0, The Rear Admiral, and SD2IEC GEOS bounty.  All-in-all, pretty good stuff for Commodore fans.

I love pic#2 !     It looked like that last week here, but has since cleared up... although it was never piled up against the door that high... I hope you have a strong back, a snow blower, or healthy young relatives to help clearing all that

Edit
Ummm... now that I think about it... what part of Chicago is that???
/Edit

I will second that opinion, as I am currently working on the same thing... there is an option to upgrade the firmware (EEPROM) if a special file found during start-up.... this is specific to the uIEC and has nothing to do with Commodore 128 BOOT command.

I answered assuming you want to know which computers I now possess.  I don't use my C64 since I got my C128 (but I still checked C64).  Friends/family have killed former models VIC-20 and Plus/4 (not checked).

I have ancestors from Lousiana, does that count?  When I was a wee lad, I spent a few years in the Orange / Beaumont area of Texas, right across the border.  Later when I would visit relatives, me and my cousins would make quick trips across to LA to get alcohol... this was back when 21 was legal and Texas but 18 was legal in Louisiana...

In January 2001, after seeing Pink Floyd the previous December, I got harassed by LA State Troopers.  They set up a speed trap on the other side of a hill, when I came over the hill, I had to slow down along with everybody else on the highway... it was a bottle neck... I got pulled over and searched for "following to close".  I wasn't following any closer than the other drivers, but I did have out-of-state license plates... always a good reason to harass a citizen.

After the search, the troopers did semi-apologize and said they had been having problems with gun runners and drug smugglers... but they still gave me a ticket... which I may or may not have paid... 

Awesome image!  The "eye" of the storm (the big red swirl) seems to be almost as large as the state of Texas, which is like a whole other country if you believe the travel ads.  Having spent many years along the Gulf (of Mexico) coast, I've become accustomed to these every two years or so... but I've never seen one that big! 

All I can say is "batten down the hatches" and be prepared for clean-up.  Hopefully you won't suffer wide-spead looting like we had after hurricane Katrina...

Glad those error reports were before reading the new post.

You're welcome for the help.  Hopefully it will help others too and inspire some nifty new software.  It also helps me because I can look up code with the search function (thanks Lance!)

I guess you could start a dedicated site, but I'd just post here for Assembly stuff, in the BASIC section for heavy BASIC code, or in Tips n Tricks for those short snippets that might be useful.  Being a forum, not simply a static site, makes the software open to discussion and hopefully improvement.  That's my take, but I guess if you really love making websites, you could give it a go.

Silly me, I didn't realize the far call to STRLIT setup the FRESPC pointer to the end of the string... so both versions do exactly the same thing!

This got me curious as to the problem so, although I don't have a compiler here, I have my trusty MONITOR.  I typed in most of the code (without the JSRFAR copy) and tried it out.  The problem is the old string is not being flagged as garbage when it gets set to a new string.  Thus garbage collection will not release it, and you get OUT OF MEMORY.

The solution is to update the "back pointer" of the old string with "delete me" code.  This is simply the length of the old string (in the back pointer low byte) and a special $FF (in the back pointer high byte).

So this should work; replace

STRFIN
    ...
    LDA  #>PTRGET
    STA  $03
    LDA  #<PTRGET
    STA  $04
    JMP  NEWFAR      ; CALL PTRGET AT $7B0B

with this

    LDA  #>PTRGET
    STA  $03
    LDA  #<PTRGET
    STA  $04
    JSR  NEWFAR      ; CALL PTRGET AT $7B0B
STREX1 = $87CA ;SET INDEX1,A WITH DESCRIPTOR
    LDA #14
    STA 2
    LDA #>STREX1
    STA 3
    LDA #<STREX1
    STA 4
INDEX1 = $24 ;HEAVLY USED BASIC POINTER
    LDX VARPNT
    LDY VARPNT+1
    STX INDEX1
    STY INDEX1+1
    JSR NEWFAR      ;CALL STREX1 
    LDA #INDEX1     ;POINTER
    STA $2B9        ;FOR INDSTA
    LDA 6           ;REGISTER .A FROM STREX1 CALL
    BEQ EMPTY       ;ZERO LENGTH, NO DATA
    TAY             ;AFTER DATA, "BACK POINTER" LOW BYTE
    LDX #1
    JSR INDSTA      ;SET LENGTH OF GARBAGE
    INY             ;INDEX "BACK POINTER" HIGH BYTE
    LDA #$FF        ;FLAG AS GARBAGE
    LDX #1
    JMP INDSTA      ;SET FLAG
EMPTY
    RTS

I can't gaurantee that will compile because I tested it in MONITOR.  I've attached the binary I used (string.bin) and a simple BASIC test program (string.bas) which is simply

10 BANK15:DO:PRINT PEEK(55)+256*PEEK(56):SYS4864:LOOP

You can watch as the freespace pointer shrinks down to around 1040 and then garbage collection gets called and it starts over again around 65000.  This string manipulation stuff is a lot trickier on the C128, but it has a huge benefit.  The garbage collection removes about 63K of junk in less than 2 seconds.  Of course in a real application it might take an extra second or two.

BDD, I thought you would mention that!  Well, you can poll the VDC during an IRQ if you know it is not in use by another thread.  If the user only access the VDC through KERNAL routines, and if you sniff the stack for relevant KENRAL address, then it is possible.  But that is to many ifs for me, and apparently, the BASIC authors.

Well, I guess you could also set up a "I am accessing the VDC" flag, but that is not made available by the KERNAL or BASIC either.

So the way the system was designed, it is not safe to poll the VDC during IRQs.  But I still wonder why they didn't make a PEN() command to tell when the VIC gets a new value.  The PEEK method I mentioned is a bit of a hack more suited to the C64 or VIC-20.

ruthven, the reason a .G64 is is normally 326K is because it has all the data of the disk, in GCR format, even if only some of them are used.  A similar thing is true with .D64 which will normally be 170K no matter if it contains only a single 1 block file.  A .D64 is about half the size of .G64 because the data is binary (not GCR), and the recording speed, sync marks, sector headers, and sector gaps are missing.

You normally only find images in .G64 format if they have copy protection that hasn't been cracked.  Once the protection is broken, it should be possible to put it on a .D64 ... this is not to say the all .D64 are cracked versions, as many lame copy protection schemes can be emulated with the .D64 "error code extensions"

To do a complete job, you will have to unsolder the locking keys.  On the C64 and VIC 20 you could get to keys by the RETURN without unsoldering, but anyway, you have trouble with keys next to SHIFT LOCK so you gotta remove it.

Like BDD said, experience isn't neccessary.  With some components, especially transistors and diodes, you have to worry about over heating the component.  You also normally have to worry about overheating and tearing traces off the circuit boards.

But with the lock switches, there is really not much harm that can be done.  Worse case is you might melt some plastic by accident.  One tricky thing is the wires connected to the switches might be looped around the pin a few times, so some twisting with the help of needle nose plyers (sp?) may be needed.

Maybe the most important thing is be careful where you set down the soldering iron when not using it.  I can't tell you how many things I've melted through careless placement.

Umm, if you don't have a soldering iron, you can buy cheap one for under $20.  Of course you may know somebody who has one.  They would probably do it for you for free, as it would take an expereinced person about 5 minutes for all the switches.  If you go this route, may I suggest you watch him/her remove the first one, then try the others yourself.  Then you'll have another skill to add to your résumé 

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

The BOOT command sends low-level block read commands (U1 cc dd tt ss) to the device, so you must first have a disk image "attached".  One way to do this is to issue the "CD" command.  For example,

OPEN1,8,15,"CD:MY DISK.D81":CLOSE1:BOOT

Since I don't own a 1581, I don't think I've ever used the AUTOBOOT MAKER from the 1581 demo disk...

But the 1571 Test/Demo Disk also has AUTOBOOT MAKER, and it works fine for D64 or D71 disk images.

I hope that's helpful!

Thanks for sharing!  From looking at the code, it seems the problem is in your STRSTR.  It seems you set the correct data address in the string descriptor, but the wrong address in the "back pointer" used during garbage collection.

You could try replacing your code

    LDA  #FRESPC     ;FREESPC ADDRESS WHICH
    STA  $02B9       ;POINTS TO COPIED $
    LDX  #1
    LDY  #0
    LDA  VARPNT      ;MAKE $ POINT BACK TO
    JSR  INDSTA      ;OUR VARIABLE (FOR
    LDX  #1          ;GARBAGE COLLECTION
    INY              ;PURPOSES)
    LDA  VARPNT+1
    JMP  INDSTA

with this code

    LDA  #FRETOP     ;POINTER TO NEW STRING DATA
    STA  $02B9       ;POINTER FOR INDSTA
    LDX  #1
    LDY  LENGTH      ;AFTER STRING DATA
    LDA  VARPNT      ;MAKE "BACK-POINTER" LOW
    JSR  INDSTA      ;FOR GARBAGE COLLECTION
    LDX  #1
    INY  
    LDA  VARPNT+1    ;MAKE "BACK-POINTER" HIGH
    JMP  INDSTA

Just an idea... I haven't actually tested it because I don't have a compiler on this PC.  Good luck!

Boy you sure are having a lot of trouble finding a working program, LOL.  The G64 files are 1541 disk images in raw GCR format.  This preserves an exact copy of the disk data.  It is supported by VICE.  As for others...

   
• Star Commander documentation says it supports GCR Format (but does not list a file type, like G64) and it also says "Comming Soon... GCR support" so who knows?
• According to the project page, G64 is not supported by CBM-Command, but Payton Byrd could tell you for sure.
• According to the info page, G64 is not supported by 64HDD.
• I don't think the uIEC supports G64 either (the info page is very vague); my device does not, but I don't have the latest firmware...

I have no idea what a NIB file is, but it sounds like it might be a GCR version as well.  All the G64 disk images I have are 326 KB, which is almost what you reported (336... umm... a typo?)

FYI, the D64 images are "cooked" versions of GCR data.  This makes for smaller file size and faster transcoding, but is not good enough for all disk images (in particular, those with "extreme" copy protection), so that is the reason for the G64 format.

Sorry I don't have a link to a good light pen program for you, but maybe some of this info is usefull.

I am glad you solved the problem, but I don't understand the solution.  Was the problem register $1c, or was the problem vdc_write ?

I think maybe you mean change like this ...

vdc_write:
 pha
 lda #$1f
 sta vdcstatus
 pla
notyet:
 bit vdcstatus
 bpl notyet
 sta vdc_rw // writting to VDC
 rts

Or maybe something different?  It would be nice to know for sure.  Thanks.

Just a few minutes ago, I went outside to get some firewood.  When I opened the door, I could see the buildings, fields, and trees clear as day.  A snow covered day mind you.  But it is like 2:15 in the morning.  I was really freaked out for a moment... like I had super human night vision or something.

Then I stepped out from under my porch and noticed there was a full moon.  Normally a full moon will allow a limited sort of vision, but when the ground is covered in snow, everything is remarkably visible.  Almost 4 decades now on planet Earth, and it's the first time I ever noticed.  Call me slow. 

Also, doing donuts in retailers' parking lots is fun!  I recommend doing this after closing time to reduce the risk of damaging other people's autos.  Of course if I lived on planet Hoth, I might have a different opinion...

Well I tested the program you posted and it works okay in VICE and on my flat C128 (NTSC, 16 ki VRAM). 

Off topic
Because your program is for the 80-column, it made me finally get around to re-wiring my S-Video adapter... so thanks!     Unfortunately, I completely lost dark gray... strange because it was working before (I have screen shots to prove it). Normally I would suspect my wiring, but the components are soldered and all the other colors are working... hmmm...

On topic
The problem is somewhere else.  Double check to make sure you set bit 4 to "1" in register $1c because you have 64 ki VRAM.

From my personal ROM (original buggy 1985 version), and the international version supplied with VICE (1986 version), it seems the KERNAL initializes register $1c with $20.  (This should be okay for addresses less than $4000 in VRAM.)  But if you have 64 ki VRAM, it should really be set to $30.  This error normally won't be obvious until you access VRAM > $4000 on a real C128.  The error will never appear in VICE until it implements correct VDC to VRAM address translation.

Finally, the program you listed was for uploading data into VDC RAM.  If you have trouble copying VRAM, (using VDC copy operation), then you should start another thread.  These are two completely different issues.

Quote from: gsteemsoPS: Ruthven, I’m pretty sure light pens will only work in port 1 regardless of other considerations, because port 2 doesn't have the connection to that detection circuit. Anyone know if I’m remembering that correctly?

You remember correctly.

Quote from: ruthvenAlso, my program uses BASIC 7's PEN command to check coordinates; I wonder if PEEKing the appropriate addresses would be quicker/more efficient... perhaps compiling the program would improve it's performance as well.

You do not want to use PEEK, because you can get mixed values -- X could come from one sample and Y could come from a different sample.  The PEN command will latch both X and Y simultaneously.  There shouldn't be any lag in the PEN command itself, as it simply reads the VIC registers from the last time a value was latched.  Of course the rest of the program may be too slow, in which case compiling would help.

One strange thing about PEN, is it can tell you when new values are available for the VDC, but not for the VIC.  I think this is because the VIC can be safely polled during IRQs while the VDC can not.

Anyway, in BASIC there are two methods to determine when a new PEN value is latched.  The first is the way it was designed.  Use COLLISION to specify a BASIC subroutine to execute when a new PEN value appears.  This is equivalant to writing IRQ code in BASIC.  Anyone with IRQ code experience knows this can be tricky, and putting this method into interpretted BASIC is very questionable to me.

Another method is polling.  You can check $11EA, via PEEK(4586).  If the value is 0, then no new value has been latched since last time you used PEN(1).  Because PEN values are sprite co-ordinates, 0 would be way above the top of the screen, so you can be sure it is not a real value.  Also note the $11EA value gets reset to 0 only when you use PEN(1) to read the last value latched.

Well, I hope some of that was helpful.  More importantly, I hope I didn't confuse you!

Ah, the Colecovision.  Seems like I had one once upon time, as I remember playing Turbo with the stearing wheel adapter.  I don't know what happened to it, haven't seen it years.  I didn't sell it... who knows, I move around so much, it could be in any state.  Well, not Hawaii or Alaska

I also remember thinking about buying the Adam.  Now I'm glad I didn't.  But still, I wonder what it would be like to program?  As I recall, the graphics seemed comparible to the C64, but don't remember much about the audio.

I'm glad the replacment board worked, and I think it was a good call on shutting down due to un-heat-sinked video chip.  If it's anything like the VIC-II, it gets REAL hot and definately needs the metal shield / heat sink.

I haven't used an assembler on a C128 in years, but I guess Buddy would be my preference.  Can't really answer your questions about it because I do most ASM developement on a PC with a compiler called Xa by André Fachat (can work on Unix, Windows, Mac, etc.) 

When I need to test something on a real C128, I use MONITOR.  I love it... 1 second boot time!  Beat that iPod, Windows, Mac, Amiga, CP/M, Unix, DOS, PSX, XBox, PS2, XBox 360, PS3, blah, blah, blah... suckers! 

If you insist on native C128 deveopement software, be sure to avoid GeoProgrammer.  Ummmm... maybe it is okay with REU and SuperCPU ?  I wouldn't know.

I still haven't got a chance to assemble and test your code.  I was working again on my taxes today.  If I were smart, I would buy some accounting software like QuickBooks.  But instead, I have to write my own database application.  Call me a compulsive programmer, I don't care 

In case you don't know, one major problem with VICE is it does not handle VDC to VRAM address translation correctly.  Here you can read quite a technical discussion about it.  Anyway, you should check to be sure you set the VDC to the correct RAM setting before doing anything to VRAM.  This is bit 4 of internal register $1c, and should be 0 for 16 kiByte or 1 for 64 kiByte of VRAM.

To summarize the above-mentioned thread, VICE will work no matter what VRAM size it uses.  But on a real C128, if register $1c bit 4 does not match the VRAM size, then data will get scrambled.

Also, I just noticed that other bits of register $1c control the location of the character set.  Because this is what you are trying to change, it is very likely the problem.

Good luck!

Thanks for your feedback, saehn!  There is really no optimal setup, as this is still alpha software with no specific optimizations.  Well, a mass-storage device like uIEC or CMD-HD is highly recommended because C1581 has space for only the shortest videos (all the videos I released in .d81 format are cut short).

Anyone with a CMD-HD or C64HDD to report results, I would appreciate it!

Now that I think about it, PAL has a slight speed advantage due to larger border = more 2MHz time.  But the video is (loosly) locked to the audio which is (strongly) locked at approximately 7843 Hz, so there shouldn't be much difference between NTSC and PAL.

The sharp reader may have noticed I said approximately 7843 Hz.  This is the sample frequency used to encode the audio, but the player will actually be off by a few dozen Hz depending on national standards.  It should play at 7819.4 Hz on PAL, or play at 7867.2 Hz on NTSC.

In other words, NTSC would run about 0.6% faster than PAL.  See?  Not much difference.  Another way to think about it is NTSC videos will be 0.3% too fast and PAL videos will be 0.3% too slow.  As an example, a one hour video would be off by about 11 seconds (plus or minus, depending on PAL or NTSC standard).  Note this is just a calculation...  I haven't made any 1 hour videos to verify this value!