My first post - yay!
Hi all,
I recently (finally) got round to restoring a PCW8256 that I picked up some time last year. I was amazed when it worked first time after plugging in a GoTek, so all it has needed is a deep clean and a little retro-brighting. Should probably re-cap, but there is no sign of any bulging or leaking.
I wanted to have it showing a slide-show in the background while I'm on a video call. There are lots of helpful tools, like @JohnElliot (http://www.cpcwiki.eu/forum/profile/?u=2402)'s PICTOOLS, but most of them work with Stop Press Canvas (.SPC) image files. A lot of googling hasn't yielded any useful tips for how to convert images to SPC format.
So I wrote a small python script to do just that. Sharing here (https://github.com/OliWright/MakeSPC) in case somebody finds it useful. I know that @Starglider (http://www.cpcwiki.eu/forum/profile/?u=1320) likes to have his PCW8256 running in the background of videos :) .
I've attached a demo disk image with a 3 image slideshow. That's all the room there was on a single-sided disk :laugh: .
EDIT : I've made an online version of the conversion tool (http://oliwright.pythonanywhere.com/). It requires me to press a button every 3 months to keep it live, so if you would like to use it and it's not working - just ping me.
Using the Gotek you should be able to use DS, 80 Track formats too. This would provide about 0,7 MB space on a DSK / Hfe Image. :)
Thanks for the demo.
Got the .DSK transferred to a real disk, and had an initial play. All working.
Going to try to re-arrange things, so it all runs off my uIDE setup. Main benefit a much quicker startup.
I note the demo uses J15ACPM3.EMS as the system, is there any significance in this, and what does the A indicate. Will another system work as well?
Interested in the SUB utils, esp the GOTO. I think I've seen these before, long ago. Might even have a disk with them all on, if I can find it? Was there some sort of IF variant as well?
Oh, is this intentional? The PROFILE file refers to SETDEF, but this prog is not there. I've just added it, and there seems to be no problem (re space for the temp files created by SUBMIT).
Thanks again.
Geoff
QuoteUsing the Gotek you should be able to use DS, 80 Track formats too. This would provide about 0,7 MB space on a DSK / Hfe Image.
True - but I was hoping to get it working on an actual floppy at some point without all that tedious mucking about flipping disks :)
QuoteGoing to try to re-arrange things, so it all runs off my uIDE setup. Main benefit a much quicker startup.
Awesome - thanks
QuoteI note the demo uses J15ACPM3.EMS as the system, is there any significance in this, and what does the A indicate. Will another system work as well?
Honestly - I have no idea. My CP/M knowledge is somewhat rusty. I downloaded PICTOOLS from here (https://www.z80cpu.eu/mirrors/www.seasip.demon.co.uk/Cpm/software/amstrad.html) and a blank CP/M system disk from here (http://www.retroarchive.org/maslin/disks/amstrad/index.html). Then followed some of the instructions in the PICTOOLS doc.
QuoteInterested in the SUB utils, esp the GOTO. I think I've seen these before, long ago. Might even have a disk with them all on, if I can find it?
Oh - I can't remember where I downloaded the sub tools from - I'll try to find it. I did notice that the goto doesn't work if you try to use it straight from PROFILE.SUB, you have to launch a new .SUB file with SUBMIT.
QuoteOh, is this intentional? The PROFILE file refers to SETDEF, but this prog is not there. I've just added it, and there seems to be no problem (re space for the temp files created by SUBMIT)
No, that's an accident. I was trying to delete everything that wasn't referenced to make space, but it looks like I got a bit too trigger happy :picard: . It should be loading everything into the ram drive and running from there. (I've fixed and re-uploaded the disk image in the original post)
Hmm, I think the system version you're using here has been 'tweaked' in some way, maybe to handle the extra SUB commands? If I try to run the process using another system file then it seems to lock up, but I need to do some further tests.
Your system file is version 1.5, this version does NOT support the .FID etc files needed for the uIDE system.
So I need to trace where you've got the .EMS file from, and try to determine what's been done to it.
However, as set up, it does work, and this is neat. Need some more 'interesting' pics? I've got a B: drive, although mine is merely 340k (5.25") but this would allow 10 or 12 extra pic files if the system runs from A: and gets pics from A: and B:.
Geoff
Subtools can be found at Chaos Cottage (https://www.chiark.greenend.org.uk/~jacobn/cpm/cpmfiles.html)
EMS file from the CP/M 3 image from retroarchive (http://www.retroarchive.org/maslin/disks/amstrad/).
Hello Oli,
Thanks for the two links.
I'd got the PIC file from John Elliott's site, and I see the various utils in there. No mention of needing a special system version, so at the moment it's likely I was doing something wrong. I need to play further.
The new link to 'subtools' may be worth looking at, but I'm not sure these are for CP/M 3. I'm pretty sure that the SUBMIT system is different between 2.2 and 3.0, so I don't think utils for one will work with the other. I'll see what I can work out anyway.
I've got a .TD0 file for a system disk, maybe that's the one you got? I've got something to expand a .TD0 file. But I guess that this is just the main file, no notes to explain it.
I'd not heard of a version 1.5 before. Checking John Elliott's web page for the system versions, he does not mention a version 1.5, and certainly not a file named J15ACPM so I'm not sure what this is. It would be an 'unknown' one if it's real. I've not seen an 'A' used before, although that position has had versions with F, S and G there for French, Spanish and German. I'll need to compare the files at a byte level, but I'd think that the most likely thing is this is 1.4 (a very common version) that's been slightly tweaked by someone (unofficial) but WHY? Anyway, John will see this I'm sure and chip in!
I'll keep playing. It would be useful to get this slideshow process to work with the uIDE drives, then could have MASSES of pics to cycle through!
Geoff
I chanced upon a method to convert a .td0 image into a .dsk image, using the Joyce emulator. If you add the td0 as a boot disk, then Joyce will make a boot.img file in its Boot folder.
Thanks OliW, but I've activated the image you originally did, and kept a copy of everything that was on it. There are also other pieces of software tht will translate a td0 file. If I remember, that format is a very simple compression system, it just spots repeated data and replaces the data with a code and a number of bytes so 10 spaces would become something like 20,A. Easy to sneak the code for that into Joyce?
Aargh - seems I do NOT remember. I'm mixing up the TD0 format, which is used by the TeleDisk system, and the IMD format used by Imagedisk. Anyway, IMD enables conversion of the td0 file to imd, and thence to raw BIN, which is readily convertible to .DSK image.
Geoff
OliW,
Regarding your version of the system file, J15ACPM3.EMS, I've now done a compare byte-for-byte with the system file J14CPM3.
I note that there are 9 bytes different, and one of those I can explain as the change for the startup screen going from version 1.4 to 1.5. The other differences are all indiv bytes, apart from the last two which are a pair of bytes. Very little change in fact.
So, I've prepared a .ZIP of the .EMS and the differences, and this is on its way to John Elliott. Well, he does say on his web page where he lists and details all the system versions that if anyone finds a version he doesn't know about than do let him know.
Maybe he can explain what the differences are about.
Geoff
Indeed I do, and thank you for drawing my attention to it.
The following bytes differ between J15ACPM3.EMS and a stock J14CPM3.EMS:
00000213: 04 05 -- Displayed version number is 1.5, not 1.4.
00001813: 23 27 -- Key adjacent to [Return] produces ' rather than #
00001881: 27 B1 -- Shift+6 produces ¢ rather than '
0000188A: A3 23 -- Shift+3 produces # rather than £
0000197C: B1 A3 -- Extra+4 produces £ rather than ¢
00001C61: 63 6B -- System messages use 'disk' rather than 'disc' spelling.
00001C6A: 03 00 -- Printer language defaults to US rather than UK
00002DAF: B0 90 -- Some printer initialisation data, possibly related to line
00002DB0: 13 12 spacing.
Given the above changes, I'm pretty sure that 'A' stands for 'America' and it's a US version.
What does make me wonder is that although the file signs on as version 1.5, the CD VERSION call still returns 1.4. If this modification was done at source by Locomotive, it seems a careless omission.
John,
I'm sure you're correct, the archive of images that OliW got the original image from contains other images that seem likely to be US versions.
Anyway, for the record, I've now got the original image file and converted it to Raw BIN, and accessed it thru Joyce. There is nothing else of any interest in that image, everything else seems standard.
Also, thanks for the note re the changes from 1.4. Cosmetic only, for the US market!
Geoff
Hello OliW,
Just wondering about finding some other pics for slideshow?
I've still got my old Sony Mavica FD7 camera, the one that takes digital pics and stores to floppy disk. Supposed pic resolution is 640x480, which is OK as regards the 4:3 pic size, so no cropping required. Maybe not quite big enough, but space for some text underneath? Would using these images make things any easier, or might I just as well use any images?
Geoff
Nice detective work on the 1.5 version - strange that a US localisation was considered an upgrade ::)
I don't think 640x480 images would make things any easier. The Python script uses Pillow (https://pillow.readthedocs.io/en/stable/) for the image rescaling and 1-bit dithering, so it's comfortable handling a large range of image formats. I could add some automatic cropping if that would help, but it would be naive in that it would take the centre 4:3 section. Or I could add a command-line option to specify the crop region. Let me know if either of those would be useful.
Hello Oli,
Just interested in the 'why' regarding the 1.5. John Elliott's web site has a page that lists and details all the 'known' versions of the PCW system, and I've met up with many of them over the years, but I always wondered if there might be others. The website suggests that there are some 'missing' ones (as in, not included in the list now) that OUGHT to exist. So when you introduced me to one, I was interested! Not only the new number, 1.5, but also the 'A' as well. It seemed sensible that it might be very similar to 1.4, so it was worth trying the FC command, and when it produced 9 changes ONLY (as opposed to pages and pages of them) then 1.5 was clearly not a real 'new' version but just a 'tweak', but was it official? Pretty sure it was done for the sales push in the USA, but that didn't last long, so nothing done re any of the later versions. Maybe John E will update his web page now?
I'd guess that the image file you found originated in the US. Nothing else of any interest on it!
As for the pics, I was looking at the github site and I note that I'd need python and pillow to do anything with your code (as python is an interpreter process only, I understand). My main machine here is XP, so the current version of python is no good, and I'm not sure that if I installed the older version that the pillow stuff (graphics libs) will work, or lead into other problems. OK, I've got a W7 laptop, but it's a pain in the ass in many regards, and I HATE it when W7 refuses to let me do many things I'm used to doing with XP (i.e. the Command Prompt in XP). I have used some fancier compiler systems on the laptop, but they all work OK at the command prompt via batch files etc and I can get things set up that I'm comfortable with.
I may get your .py file anyway, and look and see what I can do with it. I've got, and have done things with, the big FreeBasic system which accesses a lot of external libs, and there may be many of the same libs re graphics things there, and if there is then I can create an .exe at the end of the day? I'll let you know.
Thanks again.
Geoff
I'll have a look to see easy it is to convert to a .exe
Quote from: GeoffB17 on 13:22, 18 May 20
Maybe John E will update his web page now?
Already done. Assuming the numbering is continuous from 1.0, the versions I don't have are:
- 1.0 - if it was released publicly.
- 1.3
- 1.6
- 1.8
- 1.10 / 2.10
- 1.13 / 2.13
John,
Thanks for the update. I'll watch out for the others, although it was total chance we found 1.5!
@OliW (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3740) - thanks for the offer, but...
I've found a software package on an old HD, called Graphic Workshop, from 199?. This has quite a few options to manipulate images, and might be a help.
I've just been trying to get a .JPG into something close. Firstly, I re-sized the pic to 720x256 pixcels, which distorts a little, but can crop the original etc to start from something else (here original was 640x480). Then, there are various dither options, need to try which one looks better. I saved the result as .BMP (no .SPC option of course) but the data looks very good, apart from a header, and maybe something on the end. File size should be 23040, my file is 23614, but maybe just need to cut off the garbage top and bottom. Easy enough to do that. Other problem, .BMP file supposedly stores data bottom to top, so need to swap around the lines, but a little prog could do that while removing the excess.
This is 'vintage' DOS software, by the way. Need DOS to run it. Works fine under XP!!
Worth experimenting with??
Geoff
OliW
Now sorted the structure of the .BMP file.
There's a 62 byte header, then 256 lines of 90 bytes, each with 2 bytes 'pad' to make a total for each line of a multiple of 4. No further 'garbage' on the end as I suggested before.
BUT, the lines in the file are bottom to top, so the data needs to be read fully from the file, into an array, then written back to the .SPC in reverse order, i.e. last line first. SPC file is data ONLY, no header, or anything.
GW7 has 7 or so varieties of dither, plus other options that will change the picture and possible change the effect of the dither. Interesting to experiment.
Geoff
Hi Geoff,
It's a bit rough around the edges, but try this (http://oliwright.pythonanywhere.com/). I can probably make it prettier if it's useful.
Hopefully it works in whatever browser you have on your XP system :)
OliW,
Wow, thanks.
Yes, it seems to work, in that it's created a file. I need to transfer it to my PCW and see what happens.
Actually, late last night, I'd sorted an image using the GW7 prog, and got it as a BMP OK. Then, I'd written a prog using QB (QuickBasic) and compiled that to an .EXE to do the final bit of conversion. The resultant file was the right size, and looking in it, the data seemed OK.
This morning, I tried to run it on the PCW, and - eeer, hmm? No joy! Aspects of the pic are visible, but not in the correct places, so something is wrong. Looks like I'm missing something re the format of the .SPC, or the format of the .BMP - otherwise things looked hopeful.
At least, I can compare your file, just created, with my file, created last night, and see what's happened.
BUT, your process seems to work fine. Yes, the 'ergonomics' are not perfect, but totally fine for me. Certainly 100% functional.
I'll let you know what happens next.
Thanks again.
Geoff
Oli,
Your .SPC file works perfectly, the image displays exactly as it should. Great.
The file is the same size as the one I created. BUT, I was working on the image being 90 bytes wide, your image does not show 90 bytes wide (but the earlier files like 2.spc does do so. Your new file has a black band either side of the image, and I'd wonder if the problem with my image is something to do with that? BUT, the files are the same size, and the size is correct for 720x256 bits.
I'll look further.
Geoff
Oli,
Compared the data in the two files, and quite different.
Clearly, my assumption about the format of the .SPC file must be wrong. I assumed that it was a straight bit pattern, nn rows of nn bytes. For the files in the slideshow, each full screen, 256 rows of 90 bytes, giving the 23040 file size. No headers, or anything, 100% data.
Seems this is not so. Not seen any better info on the web. Do you have a note of what the format actually is?
Geoff
As I recall it follows the layout of the PCW's screen memory, so 30 lines each containing 90 8x8 tiles.
Hmm, should this be 32 lines, rather than 30? So each tile is 1 byte wide, and 8 lines high (8x8 bits)? So if I'm starting with .BMP type data, already inverted bottom to top, I need the first byte from the first line followed by the first byte of the second line .... first byte of the 8th line followed by the 2nd byte of the first line .... 2nd byte of the 8th line followed by the 3rd byte of the first line... etc? I'll try to see how that fits with how my file shows on the screen, but it could tie up.
Geoff
This code snippet from the convertor probably explains it better than words...
for y0 in range(kYDimDiv8):
for x0 in range(kXDimDiv8):
for y1 in range(8):
byte = 0
for bit in range(8):
y = (y0 << 3) + y1;
x = (x0 << 3) + (7 - bit);
if im.getpixel((x,y)) != 0:
byte = byte | (1 << bit)
data.append( byte )
It follows the memory layout of the PCW, which is in character blocks. 8 consecutive bytes are stacked vertically.
Ah - I missed your previous post. Yes - you've got it. I'm making SPC files that are 720x256, so that's 32 character rows high - yes.
Thanks,
Yes, I'm comparing the data in the .BMP I made, where the data starts at the end of the file, to .SPC that I created on the line-by-line format, and the version made by your process, and the data ties up. I can see the pattern. I just need loops within loops and build up 8 lines at a time from the .BMP data and it should work. Touch wood! Important thing, the .BMP data is essentially correct, just in completely the wrong order!
Geoff
Hello Oli,
Right, made some changes to my QB prog, rearranged the loops, and just recompiled and run.
Seems to have produced a file that looks much better. The 'patterns' of the data looks just like your version, and totally NOT like my previous version. Still got the same file size! I'll get it copied over to the PCW via floppy disk and test it.
Oh, I attach the two further 'slides' I've made so far. The TEAC one is one of my big tape recorders, the original photo for this was taken with the Sony Mavica 640x480 resolution. The other pic was a pic I've had on my computer since early 90s, I'm sure it wi;; have been a print photo then scanned, NOT I'm sure taken as a digital photo, but I've always had a soft spot for the image!
Later.. Just tried the latest product of my conversion prog, and this one is working fine, so the info regarding the format of the .SPC file is correct. Thanks
Geoff