Looks outright charming, congrats on the release!

ooh looks very nice, thanks for sharing!!!

Nice! Is that first screenshot in the 320x200 mode with cyan, magenta and white palette? If so it looks great considering the limitations!!

4xtx wrote on 2023-04-12, 13:02:

I suggest using a faster PC to generate the puzzles, then copy them over to your XT/286 otherwise you may be waiting a while..
Example: 4.77mhz 8088 took 6:25 to generate a puzzle based on keyword: 'words'
A pentium 3 gets it done in less than 1 second.

Are you planning to do some optimising next? 😁 I'm pretty sure I never profiled anything I wrote in QB, but in case you're not aware I see that https://github.com/geneb/QBPlus apparently includes a profiler. I just found this from looking at geneb's repositories because I remembered he open sourced stuff which was originally released by Crescent Software or whatever it was called. I don't know what other options might be out there for profiling.

doshea wrote on 2023-04-14, 08:05:

Nice! Is that first screenshot in the 320x200 mode with cyan, magenta and white palette? If so it looks great considering the limitations!!

4xtx wrote on 2023-04-12, 13:02:

I suggest using a faster PC to generate the puzzles, then copy them over to your XT/286 otherwise you may be waiting a while..
Example: 4.77mhz 8088 took 6:25 to generate a puzzle based on keyword: 'words'
A pentium 3 gets it done in less than 1 second.

Are you planning to do some optimising next? 😁 I'm pretty sure I never profiled anything I wrote in QB, but in case you're not aware I see that https://github.com/geneb/QBPlus apparently includes a profiler. I just found this from looking at geneb's repositories because I remembered he open sourced stuff which was originally released by Crescent Software or whatever it was called. I don't know what other options might be out there for profiling.

Thank you, yes - Palette 4 indeed!

To convert from original photo to dithered one I used the mighty dithertron https://8bitworkshop.com/dithertron/#sys=x86. … mage=seurat.jpg
It's an amazing utility and while not 100% accurate, it is 1bn times better than anything I would've come up with.

Thank you for the pointer on the QBPlus, I am interested in this and will give it a look. The idea of a profiler sounds good.
Hardware and (using) retro software is more my jam thesedays, I can't see me sinking in huge time to update/upgrade.

Regarding optimisations - there's a few spots (text and disk routines) that could use some redesign for speed. But I kept running into memory challenges.
It was important I keep to 384KB max as per the project goal and I don't have a lot of room right now.

xyPE - The generation of a word list based on the keyword the user enters.
My method is accurate but primative and slow, it relies on seeking text files based on possible combinations of letters.
I would like to speed that up but I also don't want it to cost much in the way of memory.
I've got a few ideas and maybe I will try to have a go at this sometime soon.

MrFlibble wrote on 2023-04-12, 13:30:

Looks outright charming, congrats on the release!

Thank you very much 😀

keropi wrote on 2023-04-12, 13:45:

ooh looks very nice, thanks for sharing!!!

cheers 😀

Well done!

4xtx wrote on 2023-04-12, 13:02:

I would love to see photos of it running on original hardware XT/286, CGA..

I was hoping to do that, but...

...I get this error (at the same address) whenever I start any puzzle. This is on a 640K IBM 5160 with CGA and XTIDE, running the full version off a 2GB CF card under MS-DOS 6.22.
The really curious part: this does *not* happen in 86box or PCem, which I set to emulate pretty an exact copy of the above machine - everything works just fine in those setups.

VileR wrote on 2023-04-14, 10:34:

Well done! […]
Show full quote

Well done!

4xtx wrote on 2023-04-12, 13:02:

I would love to see photos of it running on original hardware XT/286, CGA..

I was hoping to do that, but...

20230414_125911.jpg

...I get this error (at the same address) whenever I start any puzzle. This is on a 640K IBM 5160 with CGA and XTIDE, running the full version off a 2GB CF card under MS-DOS 6.22.
The really curious part: this does *not* happen in 86box or PCem, which I set to emulate pretty an exact copy of the above machine - everything works just fine in those setups.

Oh wow - overflow and it looks like when the timer is about to intialise.
The timer counts up using a calculation and increments a counter.
That one I might be able to trap.

Thank you so much for giving it a try, I love how it looks on a real CGA CRT (despite the crash)

I don't have a 5160 but I have an XT luggable (8086 not 8088) and CGA and that doesn't occur.
I might need to set up another PC with an 8088 and give it a test.

All the download links at https://4am.org/xywords/ are broken for me, but I suppose you might be uploading a new version since one obviously worked for VileR! The xymini.zip one however is missing a colon and probably an "s" as the other ones are "https".

I'm playing via archive.org and I've only tried using the welcome collection so far, but I'll definitely keep going! It'd be nice if once you finish a puzzle, it highlighted that puzzle in the puzzle list.

I'm now too distracted to reply to your response to me, I'll do that later 😁 Thanks for the information regarding the dithering tool though, I was curious!

doshea wrote on 2023-04-14, 11:06:

All the download links at https://4am.org/xywords/ are broken for me, but I suppose you might be uploading a new version since one obviously worked for VileR! The xymini.zip one however is missing a colon and probably an "s" as the other ones are "https".

I'm playing via archive.org and I've only tried using the welcome collection so far, but I'll definitely keep going! It'd be nice if once you finish a puzzle, it highlighted that puzzle in the puzzle list.

I'm now too distracted to reply to your response to me, I'll do that later 😁 Thanks for the information regarding the dithering tool though, I was curious!

I attached the same uploads to the OP here - but yes, a bit of a fail on the 4am links - now fixed, cheers!

Puzzle list - as in freeplay? or the collection mode?
Collection mode displays DONE above the tile and unlocks the next puzzle but freeplay doesnt record whether you have completed or not because it's a practise/free mode.

Thanks!

I was referring to the puzzle list in the collection mode. It took me a while to notice the "DONE" above the tile. I just wanted to play, not read, I guess 😁

CHILL-4 was not that chill, I finished it with 7 seconds to spare 😁 Was it meant to have a time limit?

doshea wrote on 2023-04-14, 11:43:

Thanks!

I was referring to the puzzle list in the collection mode. It took me a while to notice the "DONE" above the tile. I just wanted to play, not read, I guess 😁

CHILL-4 was not that chill, I finished it with 7 seconds to spare 😁 Was it meant to have a time limit?

I might need to make the feedback on the complete puzzles a little more visible, the little note might be too subtle.
I'll have a think about that.

WRT CHILL-4 I intended for a 3 minute limit on that one based on the amount of interlinking common words.
It's a little difficult for me to test because I also wrote the solutions and see them almost straight away haha..
Perhaps I might need to re-evaluate some of them 😀

Thanks for giving it a go.

4xtx wrote on 2023-04-14, 10:45:

Oh wow - overflow and it looks like when the timer is about to intialise. The timer counts up using a calculation and increments […]
Show full quote

VileR wrote on 2023-04-14, 10:34:

Well done! […]
Show full quote

Well done!

4xtx wrote on 2023-04-12, 13:02:

I would love to see photos of it running on original hardware XT/286, CGA..

I was hoping to do that, but...

20230414_125911.jpg

...I get this error (at the same address) whenever I start any puzzle. This is on a 640K IBM 5160 with CGA and XTIDE, running the full version off a 2GB CF card under MS-DOS 6.22.
The really curious part: this does *not* happen in 86box or PCem, which I set to emulate pretty an exact copy of the above machine - everything works just fine in those setups.

Oh wow - overflow and it looks like when the timer is about to intialise.
The timer counts up using a calculation and increments a counter.
That one I might be able to trap.

Thank you so much for giving it a try, I love how it looks on a real CGA CRT (despite the crash)

I don't have a 5160 but I have an XT luggable (8086 not 8088) and CGA and that doesn't occur.
I might need to set up another PC with an 8088 and give it a test.

Update on this one: I ran it on a generic turbo-xt 8088/640K and did not get this problem.
I might take a look at that timer code anyway, I recall making some changes after debugging an emulator (on a handheld).

4xtx wrote on 2023-04-14, 12:12:

Update on this one: I ran it on a generic turbo-xt 8088/640K and did not get this problem.
I might take a look at that timer code anyway, I recall making some changes after debugging an emulator (on a handheld).

For now, I found a bit of a clue (and a workaround).
I managed to reproduce it in DOSBox-X, with 'cputype' set to 8086. This made it easier to debug:

That ":2459" return address is placed on the stack by a subroutine just before it. The problem occurs within this code, which starts at offset 264Fh in the .EXE file:

1082D:244F 8BF0            mov  si,ax           
2082D:2451 CD35            int  35              
3
4... [stuff here gets modified by int 35] ...
5
6082D:2459 A3F20F          mov  [0FF2],ax       

The INT 35h handler inserts a subroutine call at :2454 and returns to it. The crash happens somewhere within that subroutine (which gave me a headache when I went tracing through it).

What's INT 35h then? DOS compilers typically use it for floating-point emulation - in plain DOSBox with x87 FPU enabled, the modified code contains actual floating-point instructions... so I'll assume that QuickBasic is trying to pull the same thing.
Luckily, in those emulators that do play nice with this code, all it ever appears to do is set the AX register to 8000h. So as a workaround, this can just be done directly. It's not a proper "fix", but it seems to work for me (so far).

To apply it in v1.0.1, hex-edit XYWORDS.EXE and change these 5 bytes:

1Offset 2651h,   from:   CD 35 04 9A 28
2                to:     B8 08 00 EB 03

My conclusion is that QuickBasic 4.5's floating-point emulation code is just buggy - not that I know much about QB, but there has to be a way to make the compiler not use it. Might involve avoiding float values in that part of the code altogether.

VileR wrote on 2023-04-14, 21:25:

My conclusion is that QuickBasic 4.5's floating-point emulation code is just buggy - not that I know much about QB, but there has to be a way to make the compiler not use it. Might involve avoiding float values in that part of the code altogether.

Interesting, makes sense. I can think of these possible workarounds:
Let's try QB 4.51, VBDOS 1.0 or PDS Basisc 7.x.
Alternatively, Turbo Basic/Power Basic.
PB also has many compiler options for FPU/CPU - but also a bit of trouble with CGA, if memory serves (palettes, BLOAD etc).

Or alternatively, let's use an x87 emulator TSR so that x87 emulation in QB library isn't being used.
Requires an 80186/80188 or higher CPU (80286 up), though, I suppose. 🤷‍♂️

Edit: I've been a QB user for many years, but I've spent most of the time on vintage systems (mainly ATs, 286/386/486).
So far, I've never encountered such a problem.
When I ran QB on an XT a few years ago, QB simply used the installed 8087 silently. Otherwise, before the 8087 was installed, it worked the same.

Oh yeah... since the above makeshift "patch" has allowed it to run on my XT, here are those CGA CRT photos 😀

Jo22 wrote on 2023-04-14, 21:50:

Edit: I've been a QB user for many years, but I've spent most of the time on vintage systems (mainly ATs, 286/386/486).
So far, I've never encountered such a problem.
When I ran QB on an XT a few years ago, QB simply used the installed 8087 silently. Otherwise, before the 8087 was installed, it worked the same.

Yeah, to be fair, it looks like INT 35h is being used all over the place (as well as other interrupts in the "3x" range, which stand in for other FPU opcodes), but that single occurrence is the only one that seems to misbehave at all. It "just works" until it doesn't. 😉

Maybe the value itself is a clue here... 8000h (-32768) is the lowest signed 16-bit number, so if anything is even slightly 'off' in the floating-point emulation, that might just get you an overflow. 🤷 If so, it might not be that difficult to refactor.

Wow those CRT images look great! I'm so pleased to see it working there.
So far I've only been able to test it on my mono CGA luggable and interpreted VGA -> CGA on my XT.
I had one of those style CRT's as a kid but I was lucky enough to have a EGA card which meant I could use the low-res EGA 16-colour modes too 😀

OK, on to the error - it's funny, we've approached the same conclusion from completely different angles.
Looking at the trace files (/T) I the fail is occuring exactly where I thought it would:

sTimer = TIMER
PlayTimeSec = 0
KeyTimeSec = 0

Now this looks like an innocent enough piece of code, but the error might lead me down a different path.

TIMER gets called a few times before this point:
- Before and after the loading screen starts to ensure the screen shows for atleast 3 seconds (for faster loading PCs)
- Then we have the kicker - RANDOMIZE TIMER gets called so that the puzzle keyword gets shuffled. (during 'Set up Puzzle HUD')
- I then call TIMER again to get a starting position for input. It's at this point it crashed as the very next line outputs a comment to the trace.

EDIT: Uhuh, DOSBOX-X to 8086 and Disable FPU - there we go..
I think I have a lead here, I note some lazyness in my variable management with sTimer.
It's possible I accidently had FPU enabled while compiling and didn't pick it up.

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

Incidentally, I get crashes on the archive.org DOSBOX when running the game on an iPhone - at the menu.
And I got some earlier crashes on a DOSBOX port on the Nintendo 2DS when completing a level - this was overcome by changing core type to simple.

I've made a change to the way the timer works and uploaded 1.0.2 snapshot.
I'll do some more experimenting later but I think this might've got it.. 😀

Reading around on the issue it looks like the number was the problem - I have a DEF INT declaration at the top of the program due to some other functions and it was making sTimer a default Integer which made that code unhappy. I don't know if this solves all of the problem but I haven't seen it crash since I made the change.