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
Pages: [1] 2 3 ... 6 Next
1
« on: May 02, 2013, 07:54 AM »
Steve Gray
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. Steve
2
« on: May 01, 2013, 11:50 PM »
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.
Steve
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. Steve
3
« on: April 29, 2013, 02:15 AM »
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.
Steve
4
« on: April 28, 2013, 11:11 AM »
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....
Steve
5
« on: April 26, 2013, 12:13 PM »
I completely missed this: + new turbocode is available as "-t s3" for 1571 and 1581 drives (for imgcopy
only). 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... Steve
6
« on: April 26, 2013, 05:19 AM »
What, am I'm getting something wrong or takes it really 26 minutes for transferring an .d81 image to disk?
These are the times for 1581disk:
Write to 1581-preformatted DD disk: 0:49 min
Write to unformatted DD disk: 1:37 min
Write to unformatted DD disk with verify: 2:08 min
Read 1581 disk to .d81 image: 0:49 min
A bit faster  And there's no external hardware neccessary, just a standard PC or laptop with an internal floppy drive.
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 ;-) Steve
7
« on: April 26, 2013, 05:16 AM »
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!
Steve
8
« on: April 25, 2013, 11:55 PM »
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
9
« on: April 25, 2013, 06:55 AM »
Steve Gray
I have found the copying times listed above to hold true with other D81 images I have made with CBMXfer. I have changed drives (I own more than one FD-2000), tried device numbers 8 and 9, and even changed IEC serial cables. No matter what I do, the amount of time it takes is about the same. However, a test should be done with a Commodore 1581 to see how long it takes to make a D81 using CBMXfer. I am unable to do this test as I do not own or have access to a Commdore 1581 disk drive.
At the end of making a D81 image file, I click the "Results" button and so far the last line always says "3200 blocks copied". The last entry in the string reads as 100% and 3200/3200. When I click on the image made in the left panel, it says 800 KB and 3225 Blks. How and where do I check to see if any errors are reported with an image?
[Edit: I finally had an D64 image that had errors on it. You can hear the drive rereading over and over until it succeeds or gives up and then continues with the image. Clicking the "Results" button will state an error and give the location.
Steve, the D81 image time above had no errors and all other images with no errors take about the same amount of time give or take five seconds.]
Yes, 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. Steve
10
« on: April 22, 2013, 03:27 AM »
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.
Steve
11
« on: April 14, 2013, 01:01 PM »
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.
Of course without the big prototype board which sits in your photo,
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! Steve
12
« on: April 12, 2013, 03:42 AM »
I'm still working things out but i hope to build up a prototype soon. I look forward to the eventual results.
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). 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 Steve
13
« on: February 20, 2013, 07:55 AM »
Just looking at 8296 Edit Rom for DIN keyboard, and the keyboard decoding table has been moved to $EF5F. Yes, it's a 4K Edit Rom rather than 2K for most other pets...
Steve
14
« on: February 19, 2013, 03:14 AM »
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.
Steve
15
« on: February 08, 2013, 05:32 AM »
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".
http://www.zimmers.net/anonftp/pub/cbm/pet/utilities/index.html
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 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. Steve
16
« on: February 08, 2013, 05:08 AM »
Hi all,
I'm in the process of reviving a B128, and while pulling the keys off the keyboard for cleaning, I managed to snap off the ends of two of the keyboard plungers. Does anyone know of a source for replacements, or have any spares that I can pay you for? I'm looking for two. I've attached a pic.
Or is there perhaps a more common keyboard that I could pull plungers from?
Thanks!
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! Steve
17
« on: February 03, 2013, 01:46 AM »
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. Steve
18
« on: February 02, 2013, 01:57 PM »
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. Steve
19
« on: February 02, 2013, 01:45 PM »
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...
You mean like this? http://www.6502.org/users/sjgray/projects/colourpet/index.html ;-) Steve
20
« on: February 01, 2013, 03:56 AM »
Hi,
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.
Steve
21
« on: January 29, 2013, 12:15 PM »
Hi, 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: http://www.6502.org/users/sjgray/projects/petkeyboard/index.htmlSteve
22
« on: January 19, 2013, 01:44 PM »
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
See attached d64 file for all three games: Astro-Rescue, Slime and Star Spores.
I still can't get over the intricate details of the game, eg. the diamonds in Slime when you die and the explosions in Star Spores.
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... Steve
23
« on: January 18, 2013, 01:20 PM »
I have it.
Steve
24
« on: December 10, 2012, 12:18 PM »
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.
Steve
25
« on: December 07, 2012, 02:25 PM »
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.
Steve
Pages: [1] 2 3 ... 6 Next
|
Show Posts
