Thank you for all of your help with my D81 imaging woes.
If you do not mind me asking, what version of ImgCopy are you currently using? To date, I have used version B03 of ImgCopy with CBMXfer.
No problem. Im using b03 as well.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Steve Gray
No problem. Im using b03 as well.
I found my zoomfloppy and have the 1581 connected now, so I will be doing some more work in the next week or so. I found that imaging a 1581 floppy creates an output file of almost 200K so my initial values are nowhere close. I haven't written any D81's yet to see if the size holds true for writing. I could not find a way to select turbo mode on the 1581 so I've left a message for Diddl to see what's up with that and where his files are now.Ok, so I found a few bugs. The routine to set the 1581 file size parameter was not being called at all, so effectively it didn't matter what I put there. doh. Looks like I also missed the drive type parameter when writing to 1581, causing it to fail. So... these have been fixed. I also was able to add a realtime track/sector display while imaging (just click the little "v" symbol at the bottom right. This will show exactly how much is completed. Please bear with me as I integrate it (ignore the old progress bar for now). Those who would like to test can download the May 1 release from my page. Thanks for your patience.
I found my zoomfloppy and have the 1581 connected now, so I will be doing some more work in the next week or so. I found that imaging a 1581 floppy creates an output file of almost 200K so my initial values are nowhere close. I haven't written any D81's yet to see if the size holds true for writing. I could not find a way to select turbo mode on the 1581 so I've left a message for Diddl to see what's up with that and where his files are now.
Don't use HD. There was a bug in one release (have to check notes) with batch mode enabled when it shouldn't be. Try the latest test release.
I seem to have misplaced my zoom floppy, but I was hoping to hook up a 1581 and do some testing to get this sorted out....
I completely missed this:
+ new turbocode is available as "-t s3" for 1571 and 1581 drives (for imgcopy
I may have to connect my 1581 drive after all ;-)
It's hard to keep up with all the combinations of drives, features, and commandline options...
What, am I'm getting something wrong or takes it really 26 minutes for transferring an .d81 image to disk?Many PC's DON'T have an internal floppy any more. It's nice that your PC is fast, but we're using 1980's technology here and our drives have 6502 CPUs in the single-digit MHz range. We like them anyway ;-)
What shows up in the cyan box to the right of the Disk label and ID? Does it say "1581"? It's that string that I use to set the progress bar calculation. If not, I can add an FD-2000 string perhaps and that should fix it. I wonder if the value was okay before... hmmm.
Glad you like CBMXfer!
Ok, looking at the CBMXfer source this morning. Looking at the progress bar code, I have a comment beside the 1581 case that says the value was a "guess"... Looks like I guessed very badly.
I don't have a 1581 hooked up at the moment so I can't really work on it but I did multiply my value by 4 as a temporary fix. Hopefully it will be more accurate, but it's still a guess. If you want to try it just download the test release from my site. I promise I will fix it properly in a future release.
Steve GrayYes, basically CBMXfer looks at the size of the output file. It doesn't look at the elapsed time, so what I really need is an accurate byte count of the resulting imgcopy output file. I probably estimated it and never got around to verifying it. If someone knows the output size I will quickly update the program, otherwise I'm planning on re-writing it anyway to show the actual progress and also show some indication of errors.
Sorry, looks like I wasn't even close ;-) Were there any errors reported? The method I actually use for the progress bar is to check the length of the output file, so any errors increase the file size prematurely. Of course, I could just be way off on my value too. Yes, I am planning to re-write that but got lots of other things on the go right now.
Looking at your photo at http://www.6502.org/users/sjgray/projects/colourpet/pic-d-screen-3x.jpg reminded me of my Educator 64 hooked up to a 1702 monitor in order to show color.The C64 can't generate a text screen like that! Each ColourPET character can have 16 background colours ;-)
I'm going to have to write a nice demo for it when the hardware is complete!
My prototype is now working! I have breadboarded the digital version. The breadboard is connected to the PET motherboard via a ribbon cable and also to the user port (for video signals). Then the 1084 monitor is connected to the breadboard (the 1084 is set to DIGITAL mode).I'm still working things out but i hope to build up a prototype soon.I look forward to the eventual results.
Currently there is no firmware support, so to generate colour you have to poke the values directly to ram. Anyway, it gives the PET 40x25 video with each character having 16 foreground and background colours. I still have some issues to fix but it shows that the concept works.
Check it out: http://www.6502.org/users/sjgray/projects/colourpet/index.html
Yes, I think doing a ROM check is the most sensible way. I've been disassembling the edit roms and they are a mess. The Kernal jumps to several locations directly inside the edit rom so those entry points must not move. This causes all kinds of patches and jumps in later ROMs. There are a lot of different ROMS so a checksum would work but then you have to make sure you do every known rom. Also, I've patched some roms to support C64 keyboard so checking the values inside the decode table would fail for those (unless you add my roms to your list). Oh, and don't forget localized ROMs (like German DIN) which have different key layouts...
I suppose it depends on what you are trying to do. If you're writing a game you might consider asking the user to press a key to start, like the SPACE bar then check the actual row/column to see which was pressed. Or you could use the normal keyboard reading routine for menus and have an option to define the game controls at runtime using the direct scan method.
I didn't actually use "80240.PRG" code, I just duplicated the technique of increasing the LEFT and RIGHT margins so that 40 characters are left in the middle. I used the CRTC register values from 80240.PRG on my first attempt to verify if it works... and it does, but still needs some more work. I want to add the ability to choose 40 or 80 column mode by holding down a key on bootup, and I need to look into the differences between 40/80 column printing routines (like the screen wrap table).I have actually created an edit rom that allows 80 column pets to boot in "40 column" mode, using a technique similar to the "80240.PRG" program.I do not know if 80240.prg can handle 50 and 60 Hz CBMs. But you should use a version working for 60 and 50 Hz like "4032 ANY HZ".
I have been looking in the EDIT roms extensively and 50/60 Hz makes very little difference. There are only a few differences in the CRTC registers between 50/60Hz. Ultimately the PET monitor can handle either without problems. The 50Hz pets have an extra patch to adjust the jiffy clock one tick every 5 IRQ's. So, if you don't care about the clock it really doesn't matter. There is some speculation that 50/60 is just needed to reduce eye strain with florescent lights.
In any case, eventually I'll post my findings and roms.
Hi all,There was a huge lot of B/ CBM-II keyboards, spare keys and parts on EBAY.DE a month or two ago. I got outbid... keep checking more will come.
So, somewhere, someone has lots of them. I'd be interested in hearing if you decide to 3D print replacements!
You mean like this? http://www.6502.org/users/sjgray/projects/colourpet/index.html ;-)Heh, I had missed that at 6502.org
I'm still working things out but i hope to build up a prototype soon. I'm currently studying the PET edit rom to add colour support. I have a much better understanding since working on my PET Keyboard Replacement project. I have actually created an edit rom that allows 80 column pets to boot in "40 column" mode, using a technique similar to the "80240.PRG" program.
Many thanks for the reply. I suspected the monitor might not fit so I have located a 12" LCD screen if need be. As for the keyboard, do you know which it any keyboard would provide the correct donor membrane to fit under the original so I can use the that to plug into the nettop? Or is there any keyboards that give an original look and require little modification to the case? If I need to replace the whole keyboard then I would try and fit a touch pad to where the number keys are now but to be honest this is a worst case scenario as I really want to keep the original keyboard if possible.The PET keyboards are totally different than todays cheap keyboards. They use a PCB not a membrane. It's not likely you'll find anything that will fit directly in the opening. Converting the PET keyboard matrix to a PC interface is the only way to go.
You mean like this? http://www.6502.org/users/sjgray/projects/colourpet/index.html ;-)I've been looking at ways to mount a Colour CRT monitor into the PET for a long time.Heh, even better would be a way to get the original PET to output a composite color signal into that color CRT (a la Colour PET a.k.a. CBM 8033). Perhaps with the use of the fabled 6562 video chip...
I've been looking at ways to mount a Colour CRT monitor into the PET for a long time. Unfortunately 12" tubes are rare, and even then the tubes are longer than the monochrome tubes that are standard in the PET. If you're willing to extend the back of the monitor a few inches somehow, it might be possible. Both Atari and Apple used 12" tubes in some of their monitors. I actually own a few and am hoping to try this myself at some point.
Of course an LCD screen would fit in there. I have seen 12" LCD screens. The problem with LCD screens is the PET monitor bezel is designed for a curved tube and wont look right, plus LCD screens just don't look retro enough ;-)
As for keyboard, Jim Brain (go4retro.com) has a C=KEY adapter that converts some Commodore keyboards (like C64, C128 etc) to PS/2 keyboards. Unfortunately the PET keyboards are not supported yet, and of course you probably want a USB keyboard. Jim was hoping to make a USB version but it is not available yet. Source code for C=KEY is available so if you had the skills you could try to add support for PET keyboards yourself.
There was discussion on VCF about PET's (in particular the 'SK' variety) with missing keyboards. I've come up with a simple solution that might be useful to some people. I have modified the PET's EDIT ROM keyboard decoding table to allow a C64/VIC keyboard to be used. It actually just plugs directly into the PET keyboard connector on the motherboard! For PET-SK machines you will need to make an adapter cable, or modify the keyboard connector. Then you just need to burn a new EPROM. You can find out more information, and download EDIT ROMs on my page here:
Yes, Steve rose to the challenge and was able to obtain a copy. After 30 years you'd think that all three games would have been online. This has been rectified
Haha, I've had Star Spores since it was released. Been sitting in my disk holder all these years ;-) It's too bad PET stuff in general hasn't been widely preserved, but the stuff IS out there somewhere...
Likely it's just still not finished. Because of the way I calculate the progress bar it might not be entirely accurate, especially if there are errors on the disk. So.... just wait a little and it will probably finish. It does take a while to do. If you want to see the "real" progress then click on the "Results" button. The output file will be show. However it doesn't update automatically... you will need to close and repeat.
I've been meaning to re-write that to show an actual real percentage and perhaps a sector map, but so far haven't had the time. Sorry.
B3 has the latest bugfixes, so use that. I know there were issues early on about creating properly sized D81 images, having to do with writing an error map block. In any case you usually want to be running the latest release.