Eivind, I got my hands on a Vortex86EX2 and it took similar to the Vortex86EX but with the additional core that uses the dual port RAM. I do not see anything significant in it in compare to its predecessor. Is that the reason why you mentioned that you do not thing about it as an upgrade?

ahmadexp wrote on 2023-08-03, 02:24:

Eivind, I got my hands on a Vortex86EX2 and it took similar to the Vortex86EX but with the additional core that uses the dual port RAM. I do not see anything significant in it in compare to its predecessor. Is that the reason why you mentioned that you do not thing about it as an upgrade?

What exactly did you get your hands on? A complete board with the EX2 on it, or just the SOM (I think it's called "VEX2-DIP168")?
The reasons I'm not looking at this as an upgrade is: 1. that the SOM is only sold as industrial equipment, ie., no "86Duino" consumer-oriented part with relatively low prices - but mainly 2. that I can't get hold of the Coreboot/SeaBIOS source code or software tools for this part.

As I've alluded to earlier, DMP is currently developing an EX3 variant which (in addition to being way faster than the EX and EX2) addresses the above. When that's out, I'll definitely build something around it - for now I'm focusing on the TinyLlama as a DOS system and the ITX-Llama as a DOS/Win98 system.

As always, amazing.
Here is what I got: https://www.icop.com.tw/product/VEX2-6454
Some more comments/suggestions
There is an amazing package of DOS games called REMOVED. Flynnsbit did a lot of work on it for the MiSTer project. I have been trying to make the necessary changes on his conversion tool to make it for the TL. However, the virtual CD is still an issue. I looked around and found some nice solutions on Vongos based on another fellow's comments and so far I think the least complex and more promising one is the CD-Berry where you put all the images on a Pi Zero and somehow ask the Pi to switch the image that it shows on the USB port as a CD-ROM.
That way you can have the DOS games with CD work via the menu.
The second thing I was thinking is about the OLDNET modem.
I have been playing with the PPP and it works great. However, there are some other cool things like DOS-SSH and microWeb browser that who with the EtherNet-Serial image.
Unfortunately, there is no way to switch between the two images and you can only have one or the other. Therefore, I was thinking, maybe we can have two of the ESP boards on the TL that accommodate both features.

ahmadexp wrote on 2023-08-03, 18:54:

There is an amazing package of DOS games called REMOVED. Flynnsbit did a lot of work on it for the MiSTer project. I have been trying to make the necessary changes on his conversion tool to make it for the TL. However, the virtual CD is still an issue. I looked around and found some nice solutions on Vongos based on another fellow's comments and so far I think the least complex and more promising one is the CD-Berry where you put all the images on a Pi Zero and somehow ask the Pi to switch the image that it shows on the USB port as a CD-ROM.
That way you can have the DOS games with CD work via the menu.

Maybe I'm missing something here, but why use an external solution when images can be mounted as virtual drives in DOS? Seems to me like an overly complex solution to a simpler problem.

ahmadexp wrote on 2023-08-03, 18:54:

The second thing I was thinking is about the OLDNET modem.
I have been playing with the PPP and it works great. However, there are some other cool things like DOS-SSH and microWeb browser that who with the EtherNet-Serial image.
Unfortunately, there is no way to switch between the two images and you can only have one or the other. Therefore, I was thinking, maybe we can have two of the ESP boards on the TL that accommodate both features.

Are you talking about the TinyLlama or the ITX-Llama now? (This is the thread for the latter).
I wouldn't think there'd be much use for the ethernet/slip firmware on the ITX-Llama given that it already has a built-in real ethernet port...?

[/quote]
Are you talking about the TinyLlama or the ITX-Llama now? (This is the thread for the latter).
I wouldn't think there'd be much use for the ethernet/slip firmware on the ITX-Llama given that it already has a built-in real ethernet port...?
[/quote]

My bad, I did not notice that the is already an ethernet port on the ITX

With regards to the mounting, I keep hearing that mounting the ISO in DOS is problematic which I personally did not give it a try yet. I should give it a try first to see if that is really the case before further commenting on it.

For the CD audio issue, I have a dumb and "easy" solution I think.
It would require to mod shsucdx (it's open source so it must not be too hard) and have it redirect the audio track requests to somewhere else, such as a serial port, and then on a serial port, connect a rpi pico with a DAC and SD card loaded with mp3s or wav matching the CD tracks that would read the requested audio track.

For example, say you're emulating quake's cd-rom in dos with shsucdhd and shsucdx and use that rpi pico based solution.
You install the game, etc, then you start it. Quake's code asks for the audio track for the title screen, aka "quake theme", to shsucdx. The modded shsucdx asks the Pico to play that audio track, and the Pico does just that.

At least this is my theory on how it could be fixed quickly and easily ...

I should try to make that 😀

It's definitely not the prettiest method or the most natural one, but if it works it won't require much

Deksor wrote on 2023-08-04, 14:01:

For the CD audio issue, I have a dumb and "easy" solution I think. It would require to mod shsucdx (it's open source so it must […]
Show full quote

For the CD audio issue, I have a dumb and "easy" solution I think.
It would require to mod shsucdx (it's open source so it must not be too hard) and have it redirect the audio track requests to somewhere else, such as a serial port, and then on a serial port, connect a rpi pico with a DAC and SD card loaded with mp3s or wav matching the CD tracks that would read the requested audio track.

For example, say you're emulating quake's cd-rom in dos with shsucdhd and shsucdx and use that rpi pico based solution.
You install the game, etc, then you start it. Quake's code asks for the audio track for the title screen, aka "quake theme", to shsucdx. The modded shsucdx asks the Pico to play that audio track, and the Pico does just that.

At least this is my theory on how it could be fixed quickly and easily ...

I should try to make that 😀

It's definitely not the prettiest method or the most natural one, but if it works it won't require much

That's quite the nifty solution! 😁 Shouldn't be too hard or expensive to make, at least not hardware-wise. Basically a small dongle you could plug into the serial port with a 3.5mm jack audio cable going to the sound card's line-in.
I'm guessing the hardest part would be modding shsucdx and programming the pico, but happy to assist you with tested PCM5102 DAC schematics if you decide to give it go, @Deksor!

I bought the parts right after I wrote the post, should arrive somewhere next week. I guess I can look through SHSUCDX' code this weekend. I'll be away during the week after, so I guess I'll really be able to work on this idea by the end of the month.

For baby AT computers and some ATX motherboards it could even plug straight into a serial port header (with the AT&T and DTK/INTEL variants) on the inside and use the CD audio port. No extra fluff on the outside 😀 (I hate having dangling wires on the back plugging straight back into the computer ...)

Deksor wrote on 2023-08-04, 22:40:

I bought the parts right after I wrote the post, should arrive somewhere next week. I guess I can look through SHSUCDX' code this weekend. I'll be away during the week after, so I guess I'll really be able to work on this idea by the end of the month.

Nice!

Deksor wrote on 2023-08-04, 22:40:

For baby AT computers and some ATX motherboards it could even plug straight into a serial port header (with the AT&T and DTK/INTEL variants) on the inside and use the CD audio port. No extra fluff on the outside 😀 (I hate having dangling wires on the back plugging straight back into the computer ...)

Yeah that's even better! One thing to keep in mind though: how did you plan on dealing with powering the dongle? For an external one, I'm pretty sure you couldn't get away with sipping power from the DTR/RTS pins like serial mice do (the Pico needs almost 100mA right? Plus the DAC and a potentially power-hungry SD card). So that's yet another cable! 😀
For an internal device, I guess a molex or floppy power connector would do the trick.
If/when you get to the hw design, please give me a nudge, I'd love for the device to be plug-in compatible with the ITX-Llama! 😉

Yeah I don't plan to make this specifically power efficient (I'm not even sure it'd be realistic), so external power will be mandatory. Even though for serial mice, this guy made a very nice serial to USB adapter which is pico based that do actually work with just the serial port ! https://www.youtube.com/watch?v=elgyVhlFi6k. Very impressive design, but yeah I doubt it's realistic for sound, and it's not my focus for now.

As for the PCB design, I intend to make this open source so you'll have everything you need to make your own version 😀

Deksor wrote on 2023-08-05, 00:12:

As for the PCB design, I intend to make this open source so you'll have everything you need to make your own version 😀

Nice, thanks! 😁

I think this might be the very definition of a late-stage feature creep, but I only recently discovered that the AGP standard is very similar to PCI. So much so that it should in fact be possible to basically just hook up a 3.3V-keyed AGP connector instead of the PCI one, with minimal changes to the design and more or less no extra components - since the PCI bridge chip I'm using supports 66 MHz bus speed. The resulting AGP port would accept 3.3V-only and "universal" cards capable of 3.3V operation, and be limited to the AGP 1.0 (1x) standard (266 MB/s).

Does anyone have any thoughts about this? My thinking is that even though this would be very limited in terms of raw AGP speed, it'd still be a bit more capable than PCI - and more importantly, support way more graphics cards from the ~2000 era.

I'm not too sure, while there are many cheap AGP cards that can be grabbed for next to nothing, the CPU won't really make a good use of them I think
Also maybe I'm misremembering, didn't you want to leave the mini pcie video card as an option ? Because then that would mean you could use the PCI slot for other kind of expansion cards 🤔 (Ignore this if that mini pcie port is a fever dream of mine).

Meanwhile I've done some progress for the CD-Rom thingy !
The hardware isn't even here, but while I'm waiting for it, I started looking at the DOS part. I talked about this to other people and they gave me a better idea. Instead of hacking SHSUCDX, I'm making a TSR ! Last night I managed to make a TSR that responds to the play track, pause track and resume track commands !
It's not finished yet, I need to figure out how to output to serial in x86asm/DOS, and for that, I'd love to figure out how to connect a terminal to DOSBox' serial port because that would make my life so much better 😅

Also I've had another idea for it. Instead of using the serial port (I'm still planning on making a serial port version of course), why not use midi ? That way I can make a "wavetable wannabe" that connects to the WT header and outputs straight to the sound card, or connect to the game port on the back of the PC, which does provide 5V power, unlike serial !

However I need to study midi itself a bit more, because the last thing I want is something that would mess with existing wavetables 😓

Deksor wrote on 2023-08-06, 14:09:

I'm not too sure, while there are many cheap AGP cards that can be grabbed for next to nothing, the CPU won't really make a good use of them I think

Well yeah the real strengths of AGP wouldn't come into play in a big way I think - there'd be no sidebanding for instance. So I'm thinking this would be mainly for opening up a much larger selection of cheap era-appropriate cards and maybe add a bit of speed as a bonus.

Deksor wrote on 2023-08-06, 14:09:

Also maybe I'm misremembering, didn't you want to leave the mini pcie video card as an option ? Because then that would mean you could use the PCI slot for other kind of expansion cards 🤔 (Ignore this if that mini pcie port is a fever dream of mine).

Haha, yeah I think that part was only your fever dream! The Vortex86EX only has a single PCIe lane, so no mini-PCIe here on this one, I'm afraid!

Deksor wrote on 2023-08-06, 14:09:

Meanwhile I've done some progress for the CD-Rom thingy !
The hardware isn't even here, but while I'm waiting for it, I started looking at the DOS part. I talked about this to other people and they gave me a better idea. Instead of hacking SHSUCDX, I'm making a TSR ! Last night I managed to make a TSR that responds to the play track, pause track and resume track commands !
It's not finished yet, I need to figure out how to output to serial in x86asm/DOS, and for that, I'd love to figure out how to connect a terminal to DOSBox' serial port because that would make my life so much better 😅

Yes! Sounds very promising!!

Deksor wrote on 2023-08-06, 14:09:

Also I've had another idea for it. Instead of using the serial port (I'm still planning on making a serial port version of course), why not use midi ? That way I can make a "wavetable wannabe" that connects to the WT header and outputs straight to the sound card, or connect to the game port on the back of the PC, which does provide 5V power, unlike serial !

However I need to study midi itself a bit more, because the last thing I want is something that would mess with existing wavetables 😓

I don't see why not! I'm no expert, but I think it's pretty trivial to send custom "sysex" messages to the MIDI port and have a custom wavetable adapter board interpret these, start the correct playback and send audio straight back to the sound card! Nice thinking! 😁

I made another *interesting* discover, which is really annoying ... SHSUCDHD only supports .ISO files (which makes sense) and thus doesn't expose any track data to programs willing to use the CD-Rom ...
Therefore they never ask the CD-Rom drive for tracks that don't actually exist.

Deksor wrote on 2023-08-06, 19:19:

I made another *interesting* discover, which is really annoying ... SHSUCDHD only supports .ISO files (which makes sense) and thus doesn't expose any track data to programs willing to use the CD-Rom ...
Therefore they never ask the CD-Rom drive for tracks that don't actually exist.

Didn't you say you weren't going through SHSUCDHD for the audio tracks anyways? Couldn't the hw adapter/dongle/board have .bin/.cue files for the audio tracks? Or maybe better (and more space-saving), compressed audio files?

No that's not the issue, the issue is that SHSUCDHD emulates a CD-Rom drive as we know, and SHSUCDX uses it.

Then when a game (let's say quake) wants to play an audio track, it first makes sure it's there. With a physical CD that has a bin/cue burned to it, it'll report all the tracks the CD has.
But here with SHSUCDHD emulating with a .iso only, it won't report any, and then the game will not even *try* to play audio tracks. Therefore I cannot detect a program willing to play an audio track, and therefore it's useless right now.

I need my TSR (or something else) to fake report audio tracks here. I've started looking into it, but it looks like a deep rabbit hole ... And not much is documented

Deksor wrote on 2023-08-06, 20:01:

No that's not the issue, the issue is that SHSUCDHD emulates a CD-Rom drive as we know, and SHSUCDX uses it. […]
Show full quote

No that's not the issue, the issue is that SHSUCDHD emulates a CD-Rom drive as we know, and SHSUCDX uses it.

Then when a game (let's say quake) wants to play an audio track, it first makes sure it's there. With a physical CD that has a bin/cue burned to it, it'll report all the tracks the CD has.
But here with SHSUCDHD emulating with a .iso only, it won't report any, and then the game will not even *try* to play audio tracks. Therefore I cannot detect a program willing to play an audio track, and therefore it's useless right now.

I need my TSR (or something else) to fake report audio tracks here. I've started looking into it, but it looks like a deep rabbit hole ... And not much is documented

I see! Yeah, that would deepen the rabbit hole for sure! 😁 As is often the case... Best of luck, I'm sure this will be great!

I started working on the conversion from PCI to AGP today, and ordered a bunch of AGP connectors though JLC. They were over 11 times as expensive as the PCI ones, guess not that many people are using AGP these days huh...

Update:

I've re-routed the board to accommodate an AGP slot. Aside from a couple of minor tweaks here and there, the other main difference was going back to using the SD card's signals as the source of hdd activity for the LED and clicker. My previous attempt of letting the BIOS tell the MCU when to click worked great in DOS (which uses BIOS routines for communicating with the hard drive), but not at all in Windows 98 which bypasses the BIOS for such things.

Waiting for the batch of AGP connectors to reach JLC before ordering the fourth prototype...