Hi All,
Its been a while since I've posted anything, so here is an issue I have with printing from CP/M on my 8256....
I have finally bit the bullet and purchased one of JonB's fantastic uIDE drives - After a few 'user error' issues, I have it all working perfectly ;D
BUT... (there is always a but...)
For the life of me I couldn't get v1.15 of CP/M to initialise the XDRV.FID as it kept hanging on boot up. I managed to get it all working by using CP/M plus version 2.9.
However, this version of CP/M doesn't appear to support the 8256 dot matrix printer. When CP/M loads, I get no printer "head initialisation" noise occur and if I press the PTR button, it tells me its a daisy wheel printer not the 8256 printer.
Is there any way to solve this good people?
Thanks,
Darren
Hello Darren,
First, the XDRV.FID works fine on my PCW with 1.15, so I'm not sure why your's has a problem. You don't say, is there any message from the FID that it has loaded, i.e. it announces the new drives. Just to make sure it's not that it has loaded, then had a problem afterwards. I trust also that your printer IS OK, i.e. it works OK if you boot an earlier version.
Regarding the problems with 2.9, this is really a 9512 system, and it will be expecting a daisy wheel printer. Maybe this will need some sort of drives to handle the dot matrix instead. I'll check some system disks and see if I can find anything. But before trying to get further with 2.9 I think better to sort out problem with 1.15, which OUGHT to be OK.
Looking in a disk for system 2.1 I see that there's a file MATRIX.COM. Looking in the file there's a lot of text regarding printer settings. Maybe this is the file you need, but I'm not in a position to test anything right now. Tomorrow, I'll set up a boot for my PCW, with 2.9 (which I have, but don't usually use) and extract MATRIX.COM from an archive. Also, I'll check a later HELP file as that may have some info too, MATRIX.COM is NOT mentioned in my 8256 manuals, prob didn't exist then?
Now checked the HELP data on the same 2.1 system, and this refers to MATRIX.COM being used to set the printer params for FX80 emulation, which might help, but might be something different.
Other info (John Elliott's pages) refer to system 2.1 ADDING support for the dw printer, and do not say that support for the dm printer being removed. 2.9 coming a little later should be the same. Note that systems 1.15 and 2.15 are the same, and 1.15 does still support the dm printer *If it's found on startup* (my emphasis) which is why I ask about your printer being active OK.
Oh, just found a posting on another forum from JE dated 11/07/17 where he says that if an 8000 machine boots from a J2*.EMS (or vice versa) then the machine will not access the built-in printer. So, 2.9 may not work for that reason, but 1.15 still OUGHT to, and I repeat, does for me.
Geoff
As you can imagine, I use 1.15, too with XDRV.FID.
Is there a chance there was a minor revision made to yours that makes it incompatible with the xdriver? It does pull some off piste tricks to give access to more drives (courtesy of JE).
Try the download image linked to in the uIDE info page - that's the one I use.
Are you booting from floppy? None of the CPM 1.15 files work correctly with my Gotek emulator but seem fine when using an actual disk drive. I may have to move the Gotek to B in the future.
The other way around this is to eject and re-insert the virtual floppy when the boot sequence stalls. CP/M will complain and ask to retry, abort or ignore. Retry and everything should work ok.
It does feel like the system is more unstable though which is why I may go back to booting from 3" disks.
Interesting, Geoff's CP/M v2.9 upload boots without hiccups on my 8512/Gotek
http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/joyce-emulator-using-hd/msg114112/#msg114112 (http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/joyce-emulator-using-hd/msg114112/#msg114112)
None of the other "FID capable" versions work without intervention.
I suppose the answer is hidden in here:
Quote from: John ElliotTo clarify the difference between 8000-series and 9512 boot disks: The sidedness and TPI aren't the issue. An 8512 will happily boot from a 720k drive A: if one happens to be fitted. The difference is the boot sector checksum. On an 8000-series the 8-bit checksum of the boot sector must be 0xFF; on the 9512 it must be 0x01. If you load a 9512-type EMS file (J2xCPM3.EMS) on an 8000-series, or an 8000-type EMS file (J1xCPM3.EMS) on a 9512, it'll work but won't be able to drive the built-in printer.
Regarding the last postings above, I'd be inclined to suspect the images, rather than the 1.15 file.
I'd be interested to have a look at your image, in case I can spot anything odd.
One line to investigate could be to tweak the version number, but I don't know where this is, or how it's stored in the file. The version #.## appears on the screen at startup, and I can see the surrounding text in the .EMS file, but the bytes where the #.## should be do not seem to be ASCII numbers, and may be links to whereever the #.## is stored. Or ARE the #.## but encoded in some way to hide or obfuscate? Then the system could be made 2.15 rather than 1.15 (which it happily could be, according to JE) which would be consistent with booting from a B: image, although might need to adjust the CHK as well (a CHK that is being used as a 'marker' or flag rather than an actual CHK).
I'm booting my PCW from a SS 3" disk A:, and the disk will have a normal SS boot sector. Not had any problem with this.
The sequence shows:
Blue bars down the screen.
Double click from printer
Sign-on message.
Extra message re JonB's driver, and drives available.
Activity from PROFILE.SUB
A: prompt (well, actually, on my setup it goes to C:, but that's by-the-way).
At what point do others have a problem?
Geoff
Well, just for the record.
I've used a spare boot disk, and replaced 1.04 with the 2.9 system.
Done a normal boot, and the system boots fine, but there was no click-click from the printer.
When I press the PTR key, the Printer Status bar refers to 'Daisy', and if I try to do anything now the machine locks up.
If I don't press PTR and instead try the MATRIX prog, the machine locks up.
Trying MATRIX with a boot from 1.15, the prog works, but simple resets the printer defaults (click-click) and does nothing else, but I think there are command line settings for other things. So, MATRIX affects the printer ONLY, and not the system or the availablility of the printer.
If I put the XDRV.FID on the disk with 2.9, and reboot, I get JonB's message regarding the extra drives, and a normal startup, except the matrix printer is not available. Access to the extra drives seems normal, I quickly tried C: and J:, both behaved fine. So 2.9 seems to be OK apart from the printer, but maybe if it was 1.9 this might be OK? But no point, as long as 1.15 is OK??
Geoff
Ok, here's a poorly filmed video showing my PCW booting into
1.14 (German version) - J14GCPM3.EMS
1.15 - J15CPM3.EMS
PCW 9256 image - J11CPM3.EMT
PCW 9512 image - J21CPM3.EMT
Geoff's 2.9 image - J29CPM3.EMS (including Joycedrv.fid but no drive connected)
A copy of the 1.14 image with J14CPM3.EMS replaced with J29CPM3.EMS (no fid)
1.14 (as in Nr. 1)
https://my.pcloud.com/publink/show?code=XZQeUt7ZFHPa1mb8cVQWETjsg4rdsHAGoyik (https://my.pcloud.com/publink/show?code=XZQeUt7ZFHPa1mb8cVQWETjsg4rdsHAGoyik)
Hmm, not really clear what's going on with the video, a commentary would help.
One thing though, you're getting the 'Drive not ready' message - this suggests that the problem is to do with the image format, mor specifically, the format of the image is not what the system is expecting, but when you do the 'retry' (or whatever) then it finds that it CAN read the disk and the boot proceeds.
Again, what image types are all these?
Geoff
Quote from: GeoffB17 on 18:32, 24 March 19
Hmm, not really clear what's going on with the video, a commentary would help.
what would you like me to say???
Seriously I'm simply booting and rebooting by pressing Ctrl Alt Exit throughout the video. When the image boots that's fine. If not I deselect the image, reinsert it and watch boot continue.
Quote
One thing though, you're getting the 'Drive not ready' message - this suggests that the problem is to do with the image format, mor specifically, the format of the image is not what the system is expecting, but when you do the 'retry' (or whatever) then it finds that it CAN read the disk and the boot proceeds.
Err no, it's because I'm ejecting the image because the boot process stalled. Hence no disk. Re-inserting the image allows boot to continue, cancelling the error message.
QuoteAgain, what image types are all these?
Quote
14 (German version) - J14GCPM3.EMS1.15 - J15CPM3.EMSPCW 9256 image - J11CPM3.EMTPCW 9512 image - J21CPM3.EMTGeoff's 2.9 image - J29CPM3.EMS (including Joycedrv.fid but no drive connected)A copy of the 1.14 image with J14CPM3.EMS replaced with J29CPM3.EMS (no fid)1.14 (as in Nr. 1)
What to say - a running commentary of what you're doing would be helpful. I've no experience of the Gotek. I might assume you're doing the Shift-Alt-Exit, but I wasn't certain, and the timing matters. Also, regarding the Eject/insert, were you pressing any key as well?
When I referred to 'image type', I meant regarding A: (17?k) or B: (72?k). Maybe they're ALL B: types?
Geoff
Ok maybe it just seemed obvious to me. Ejecting an image is done by pressing a button on the Gotek device, nothing else. You can see me waiting for boot to stall, reaching for the Gotek and quickly ejecting and reinserting the image (click, click). This immediately revives boot with CP/M now complaining about the drive being empty. I then press R to retry and everything is fine.
That's all I'm doing. 1.14 and 2.9 are the only ones that didn't require ejecting the image and for some reason the 9512 image didn't boot at all.
I doubt there's anything wrong with the files as such but have a look for yourself:
https://my.pcloud.com/publink/show?code=XZdNUt7Zl7TKVzH27e5zdeVMzzGHiVtV5QKX (https://my.pcloud.com/publink/show?code=XZdNUt7Zl7TKVzH27e5zdeVMzzGHiVtV5QKX)
Thanks for the images.
Initial response.
The images _29 and PCW are the correct size. The others are all too large. I'll have a look inside them and try to find out why. Maybe they are Extended type, which MIGHT be a problem but I don't know. They seem to be consistently too large.
I'll look inside some now. Starting with the 115 one, as it's the most important.
Geoff
I've had a look inside the image CPM115.
It's NOT an extended variant, so I don't yet know why it's too big.
The boot sector looks OK.
Directory area seems OK, etc.
Put the file into my Joyce, and tried to boot with it.
Errors, so Joyce isn't happy as well. I guess that Joyce is having the same problems as your real PCW.
Errors regarding initial search for ????????.FI? and PROFILE.SUB. These are both files that are looked for on startup, but they MAY not be there, and if not there they should be disregarded, so an error being generated is wrong. When I tried to do a DIR, this also immed gave an error. So there is something wrong with the image. This may explain everything.
Pending finding out WHAT the problem is, I'd suggest use the _29 image (which seems correct, and I understand works fine), and replace certain files from that with files in 115 to make OK versions.
I'll come back to this later. Right now, wife needs me for something....
geoff
Wife sorted. For now.
CPM115 disk seems OK otherwise, but the image has an extra track. I.e Tr 41. The track seems to have data, and seems normal otherwise, but it ought not to be there. The xDPB data at the start of the first sector says 40t ok, and the dir is not full, so no files should be using the extra track, so this should not be an immediate problem but it does indicate that something is wrong with the image.
The size of the image file would be correct if the extra track was not there, so the structure of the file seems OK otherwise. But clearly something else is amiss!
This disk does NOT have a .FID file, and does NOT have a PROFILE.SUB, so this explains why files not found, but system SHOULD look for the files, but should expect that they may NOT be there, and no find should NOT generate an error.
Geoff
So far, I cannot work out what's wrong with the 1.15 disk. The contents of the image are odd, and it seems that trying to boot from such a disk via Gotek gives problems, and Joyce seems to be the same.
If I try to use the same image within Joyce (i.e. no boot) then Joyce seems to access the disk fine, and I can access the files on the disk, copy them, etc. No problem.
Checking my various images, I find I have quite a few images with the same larger sizes (SS and DS formats) that I've not had any trouble with (but not booting ?) So the problem seems to be booting from, and Gotek.
What I'll offer is to use the CPM29 image as a base, create a copy image, delete all the files and put on the CPM115 system and other files to make a new boot image for you to test. Do you need the XDRV.FID?
If this then boots fine from Gotek, then we are at least 1 step forwards.
Geoff
If you like I'll take a look at the faulty 1.15 image and compare it to my own copies.
Hello John,
Thanks for the interest. I'll keep your offer in mind.
However, the problem is with the .DSK image file, and may NOT be anything to do with the J15CPM3.EMS file. To further complicate the issue, the problem DSK file may be OK on a real PCW, but has problems when booting from a Gotek drive, and also seems to have problems booting within Joyce. I suspect that the DSK in question may be malformed in some way, I'm not sure that the extra track would cause the problems.
More investigation still needed.
Geoff
Yes it's all pretty confusing, had to take a step back today and give my poor brain some rest.
Really appreciate all the input though! Since this thread was originally about printing maybe Darren would like to chime in?
Right, I've made the image as promised, it should be attached. TEST115.DSK.
This if the image file you had CPM_29.DSK, that you said worked fine, apart from not liking the printer.
I've deleted all the files that were in the DSK, and added most of the files that are on my working real 3" disk that I use to boot my PCW for system 1.15 for use with the uIDE
The XDRV.FID is there.
Certain files are there extra. CLS is a CP/M CLS prog
NSWP is a VERY useful file/dir maintenance utility that helps with all copy, delete,etc operations
SANSERIF changes the screen font to something I prefer - remove it if you don't like.
ED80 is the test editor I use, mainly WS commands
Please try this ASAP via your Gotek, and let me know. If this still doesn't work, then the problem is specifically Gotek.
Geoff
Nope, it also stalls. To be precise it stops on track 10 if that's any help?
Checked against another 1.15 image and sure enough: T10 as well.
Oh?
Bad news.
But what do you mean by 'Track 10'? Do you get a message on screen referring to Tr 10? What has appeared on the screen at the point of crash?
Geoff
The Gotek has a little display showing which track is currently being read. The PCW's main screen itself just blanks out while the boot process hangs. It seems to be waiting for a response from somewhere and by ejecting the image it's possible to kill whatever task is running. There's nothing to log any errors, is there?
Here's an idea: I don't have a printer plugged in, could J15CPM3 be waiting for a reply?
Since J29CPM3 expects a daisywheel instead of J15CPM3's dot matrix?
Hooked up the printer but no luck. It does work but boot still hangs at a point before polling the printer.
(https://i.postimg.cc/B6f78Qb3/D3-AB039-E-8775-491-D-A281-C7-C7-D9-BB11-F2.jpg)
(The first set of numbers simply refers to image 5 out of 8 selected)
No idea how Tr 10 comes into it, I'll check through the image and see what's on Tr 10. But I'm not sure that'll help.
I suspect that there will be some connection between the explicit error message that I see when I run things within Joyce. That is giving an error, and may be waiting for some response, even if just a key press. My worry is that the system has not fully completed load/install, the bank switching may not be finalised, etc Your activity with the Gotek may allow some sort of completion, but this may not be 100%.
BUT - the 2.9 system seems to load fine, for you via Gotek, and for me within Joyce. Well, apart from the printer, but I've never bothered with the printer within Joyce on the PC so I never noticed that.
I've now sent an email to JE directly.
I'll get back here ASAP.
Geoff
Hi All,
Apologies for the delay in responding - Just got back from a few days break! Thank you all for the many responses to my initial query. Unfortunately the issue I had with xdrv.fid was a red-herring so apologies for that. xdrv.fid has nothing at all to do with the issues I have with loading 1.15.
I suspect its do to with the fact I too use Gotek drives as per TynH's responses. The test115.dsk provided by Geoff also stalls on track 10 of the lcd display. Interestingly enough, if I advance the gotek to select another .dsk, I get the standard "Drive not ready - Retry, Ignore or Cancel" error. If I then reselect test115 image and select retry, it loads (and this time, it loads xdrv.fid which mine never did! - So thats a positive step anyway. Thanks Geoff)
The correct printer now loads too! :D
So the only issue i have is why a Gotek drive stalls the load on track 10 and i have to force a retry error to get it to continue....
As always, thanks all,
Darren
Note to Darren and 'TynH'.
I've had a very helpful reply from John Elliott, with a possible explaination regarding these problems.
He's sent me a copy of an earlier .EMS, referred to as 1.7H (properly 1.07H) which I understand was a special version for a Hard Disk add-on which does support .FID access.
I've changed my TEST DSK image to replace the 1.15 with this version, and I'm running some tests within Joyce, but the initial indication is hopeful.
When I'm OK, I'll post this version here, for you both to try, and see if it removes the problem.
Geoff
OK, we really need to try on the Gotek, so I attach a new image to be tried.
Note, this version is an older version of the system, so it really applicable ONLY for use with the Gotek. Anyone using the uIDE with a 'real' PCW with real boot disks should continue to use the existing (later system) 1.15.
Please let me know how this version works for you?
Geoff
Haven't tried printing but v1.7H seems to boot without any problems:
(https://i.postimg.cc/KcBCBv1R/408-A2388-9-B49-405-E-B710-76-C87823-CB44.jpg)
So what's the big secret, what do 1.7H and 2.9 do different?
If the Gotek disk emulation isn't 100% accurate there might be a chance to correct this. The Gotek's firmware ,,FlashFloppy" is open source after all, so no harm done in asking the maintainer. Well as long as you know what to ask of course, ;D
Anyway, great job Geoff and John Elliott!
The disk was set up to attach to the uIDE. Do you have that connected. The screen reports that it has not connected, so if it SHOULD have connected, then there IS a problem??
Otherwise, things look much better. That screen looks exactly like I got here using Joyce (which does NOT have uIDE!!).
Geoff
My uIDE is currently sitting on JonB's desk, waiting to be assembled so not connected! :laugh:
Browsing through
http://www.seasip.info/Cpm/xbiosint.html (http://www.seasip.info/Cpm/xbiosint.html)
but it's a bit late for me to make sense of it all. Dog is now demanding his evening walk too.
Quote from: TynH on 23:30, 26 March 19
So what's the big secret, what do 1.7H and 2.9 do different?
1.11 / 2.11 added support for the second-generation PCWs, the PCW9256 and 9512+. This means the floppy drive initialisation code was rewritten to probe for the controller and drive types. One of the things it does is turn off the drive motors and repeatedly attempt to sense the drive status until it becomes not-ready. Another thing it tries is to start the drive motor, seek to track 0, stop the motor and see what happens to the 'Track 0' signal. The Gotek might not be emulating what a real drive would do in these situations.
My information was that 2.9 was working OK for you, but gave rise to the problem with the printer. Because it was 2.xx, rather than 1.xx.
The importand difference is between the new 1.7H, and the 1.15.
John explains that the later systems, 1.11 onwards, have some code to allow the system to check the drive at boot stage to see if it's a 3" 180k or a 3.5" 730k, and act accordingly. Not fully sure HOW the software does this test. Clearly, this test works properly on the real hardware, and SHOULD work correctly on the Joyce depending on how the system is configured (mine may not be correct), but it SEEMS that the test does NOT work reliably with the Gotek drive. It may be checking the drive hardware, and not the image. Not really sure. This happens because versions 1.11 (and 2.11 onwards, they are the same) are intended to operate on either the 8000 and the 9000 series machines. Therefore, while the system is booting, it may be confused as to the disk type, and may be reading it incorrectly. May appear to have completed, but the system in memory may not be complete.
To get the Gotek to work 100%, it would be necessary to work out EXACTLY how the test is done, and this may not be practical. If 1.07H works fine, then prob not worth it. I don't think there's anything in the later versions that's THAT important.
I sent JE a copy of the 1.15 we were using, and he's checked that with his archive copy, and confirms that it's the same, so the problem was nothing to do with the 1.15 .EMS. Other than, we assume, the way the file was being read into memory??
Geoff
Thanks, that does make a lot of sense!
Probing the hardware like that to determine the drive specs sounds a bit brutal if you ask me. Not surprised if the Gotek doesn't emulate the correct behaviour.
Well it looks like I won't have to move it to drive B now, that's great!
I can confirm that after booting from TEST107.DSK, it boots perfectly, initialises uIDE and the printer all works perfectly!! ;D
As always Geoff, thank you for your investigations.
Reading the comments from John, it could well be a 'bug' in the Gotek firmware possibly manifesting itself? who knows!
Anyway, as far as I'm concerned, my initial query has been addressed and I'm about to explore this uIDE stuff.
Happy Days.
Thanks All again!
Darren