4xtx wrote on 2023-04-15, 01:34:

I don't know if this solves all of the problem but I haven't seen it crash since I made the change.

Nice! Can confirm, all is well on the 5160 now. I played through a few puzzles in succession, had my progress saved and everything, so I think it's safe to say that there are no other issues.

4xtx wrote on 2023-04-14, 23:22:

What's curious to me is: why the lack of FPU on my 8086 luggable and 8088 desktop does not cause this problem.

Yeah, I can't tell what that's all about either. If there's an elusive bug somewhere in the QuickBasic library, there may be unintended consequences due to some external factor - say something BIOS-related, or the contents of uninitialized RAM.

Anyway, congrats on nailing that one down. If you intend to develop this game further, I hope you could give some thought towards speed optimizations. On a 4.77-MHz 8088, it appears that two areas in particular could benefit: graphics-related routines, and the loading of the puzzle sets from the main menu.

I'll wager that space requirements could also be brought way down if you took all those small files and clumped them together into a single one, which could be compressed. The only hurdle is with the background images, since lots of unordered dithering usually means poor compression ratios.

VileR wrote on 2023-04-15, 09:58:

Nice! Can confirm, all is well on the 5160 now. I played through a few puzzles in succession, had my progress saved and everyt […]
Show full quote

4xtx wrote on 2023-04-15, 01:34:

I don't know if this solves all of the problem but I haven't seen it crash since I made the change.

Nice! Can confirm, all is well on the 5160 now. I played through a few puzzles in succession, had my progress saved and everything, so I think it's safe to say that there are no other issues.

4xtx wrote on 2023-04-14, 23:22:

What's curious to me is: why the lack of FPU on my 8086 luggable and 8088 desktop does not cause this problem.

Yeah, I can't tell what that's all about either. If there's an elusive bug somewhere in the QuickBasic library, there may be unintended consequences due to some external factor - say something BIOS-related, or the contents of uninitialized RAM.

Anyway, congrats on nailing that one down. If you intend to develop this game further, I hope you could give some thought towards speed optimizations. On a 4.77-MHz 8088, it appears that two areas in particular could benefit: graphics-related routines, and the loading of the puzzle sets from the main menu.

I'll wager that space requirements could also be brought way down if you took all those small files and clumped them together into a single one, which could be compressed. The only hurdle is with the background images, since lots of unordered dithering usually means poor compression ratios.

Thanks for replying back, and thank you for your help. I'm pleased that bugs done with! 😀

I'll add a third - the word list generation in xyPE - it is glacial on an XT.

With xyWords I did put a setting in to remove "fancy colors" and I find this speeds up the text-related routines and will limit post-processing in general.
There's two styles of text, one being a manipulated print command based on the screen 1 text mode and one (the smaller) are actually individual sprites that get post-processed. If you turn fancy colors off it will make the UI a bit snappier.

The redrawing of images, bit more tricky - I am just using BLOAD which is a raw binary load of the image into the video memory.
I can keep a few BLOAD contents in RAM but I started to run out of room very quickly given I am targeting 384KB (with a stretch of 320KB).

The puzzle loading (in collection mode) is slow as it needs to generate some statistics and there are a few disk reads.
This one definately could use a re-think as my original concept to display them has turned out very different to reality!

With regards to developing further - I am half and half to be honest.
This was a fun project, but it took up a lot of time and I have a gigantic backlog of hardware and software projects on the go for my main hobby.
I think I'd rather get the code to a state where I'm comfortable with releasing it as open source. Not that there is a gigantic QB community out there thesedays, but there might be some lurkers 😀

I made a detailed user manual explaining many of the games concepts, file formats, methods, etc.. so I reckon there's a good base to start from.

Maybe the QuickPak library has some optimised routines that wouldn't be so hard to drop in to your code, although I'm not sure how well the QuickBASIC linker works - hopefully it's not so dumb that it links in the entire library when you're only using part of it. Links to the library source and manuals are at http://annex.retroarchive.org/crescent/index.html; the QBPlus manual is there too.

VileR wrote on 2023-04-15, 09:58:

I'll wager that space requirements could also be brought way down if you took all those small files and clumped them together into a single one, which could be compressed. The only hurdle is with the background images, since lots of unordered dithering usually means poor compression ratios.

I was thinking about all those small files too. Even without compression, combining lots of small files into one big one would probably be a good improvement - from a quick look online and a look at an MS-DOS 3.3 floppy, for a 360KiB floppy the cluster size (minimum allocation unit) seems to be 2 sectors (1024 bytes), and there seemed to be a lot of files less than half that size.

doshea wrote on 2023-04-15, 13:23:

Maybe the QuickPak library has some optimised routines that wouldn't be so hard to drop in to your code, although I'm not sure how well the QuickBASIC linker works - hopefully it's not so dumb that it links in the entire library when you're only using part of it. Links to the library source and manuals are at http://annex.retroarchive.org/crescent/index.html; the QBPlus manual is there too.

VileR wrote on 2023-04-15, 09:58:

I'll wager that space requirements could also be brought way down if you took all those small files and clumped them together into a single one, which could be compressed. The only hurdle is with the background images, since lots of unordered dithering usually means poor compression ratios.

I was thinking about all those small files too. Even without compression, combining lots of small files into one big one would probably be a good improvement - from a quick look online and a look at an MS-DOS 3.3 floppy, for a 360KiB floppy the cluster size (minimum allocation unit) seems to be 2 sectors (1024 bytes), and there seemed to be a lot of files less than half that size.

spot on - i believe 3.3 also supports the 512byte sector format, well atleast i got it working in 86box and there was a lot less slack space, but it's not a solution.
Also 2.11 does not support it and I do actually use this for the SHARP PC-7100 (as Sharp made a custom version that can interact with its bundled RTC)

i couldn't figure out how to use one file and silently BLOAD multiple images off it and the alternative would mean flashing up 1 BLOAD image onto the screen and then doing a series of GET's to gather the images into memory while that image is visible.
I did consider this for the 360K version and still may implement it.
My initial concept was to be cheeky and flash up a Pangram (so I can steal every letter of the alphabet) and then put some fancy patterns and symbols on the screen.

im trying to avoid libraries where possible again due to memory and other dependancies/complications that come with using them (ie. declarations, common shared, etc..), i may need to look at them though - but again, unsure if I'll sink a heap of time into it at this stage 😀 conflicting priorities!

Looks amazing on a real CRT

MrFlibble wrote on 2023-04-26, 19:08:

Looks amazing on a real CRT

100% - it was one of my motivations for doing the project..

I second that! 🙂👍

What comes to mind, does anybody of you in NTSC land have an RF modulator and a 1970s CRT TV?

The IBM CGA board had an internal header for an RF modulator.
That CVBS/Composite header was used for portables, too, I heard.

I would love to see how such a game looks on a blurry TV set.
The dithering patterns might be turned into smooth gradients.

Jo22 wrote on 2023-04-27, 14:15:

I second that! 🙂👍 […]
Show full quote

I second that! 🙂👍

What comes to mind, does anybody of you in NTSC land have an RF modulator and a 1970s CRT TV?

The IBM CGA board had an internal header for an RF modulator.
That CVBS/Composite header was used for portables, too, I heard.

I would love to see how such a game looks on a blurry TV set.
The dithering patterns might be turned into smooth gradients.

I have a clone CGA card (the big full length one) which has the composite out and I have a matching NTSC compatible TV 😀
I would love to use it except its tantalums let out the magic smoke and I need to order / replace
Based on testing with emulation (86box) I found it didn't smoothly gradient - it looked horrible actually and didn't like my palette tweaks very much
BUT
I was mucking around with with this as a concept and it actually needs the dithered images tweaked to match a composite palette
think about what they did with the 8088mph pictures..
At the very least it is possible but would take a tremendous piece of work to pull this off and then fool QB into displaying it accurately

One more thing to note - the way the artefacting worked (atleast to my understanding) was to position certain color pixels next to others.
This can be generated with something like my screenshot

After I figured out the pictures might be too hard - I began thinking about colorised patterns and gradients as the backgrounds and then enhancing the UI elements to match something similar to what I'd do for EGA. The font on the other hand - really challenging given it's 5x3px and it's going to look nasty with my techniques used

4xtx wrote on 2023-04-27, 14:22:

I was mucking around with with this as a concept and it actually needs the dithered images tweaked to match a composite palette
think about what they did with the 8088mph pictures..
At the very least it is possible but would take a tremendous piece of work to pull this off and then fool QB into displaying it accurately

Not if you use CGAArt (by one of the coders on 8088 MPH, incidentally). 😀 It can do composite as well as RGB.

Be aware that there are two revisions of the IBM CGA (early/late, AKA "old"/"new"), and the artifact colors they produce over the composite output will differ. There's one mode that will look reasonably similar in both cases, which is mode 6 (640x200) with the "BW" bit of Mode Select set to 0, and the foreground color set to 15 or 7.
On the other hand, with non-IBM cards all bets are off, even when they have color NTSC output; IBM never documented or specified what the artifact colors are supposed to look like, so not too many CGA clones really bothered to replicate the same behavior.

Either way, the best approach from experience would be to re-convert the source images specifically for composite, rather than tweak the existing dithered RGB images. It also helps if you 'pre-cook' the input somewhat to better match your target mode and palette, but that goes for any conversion in general.