exxos's Atari, Amiga & retro forum

Mikerochip wrote: 15 Apr 2026 15:29

kodak80 wrote: 09 Apr 2026 09:25 Raven060 pgusinit-3.8.0a (for use with firmware 4.0.0.).7z

PiGUS v4.1.0 out. And, now considered stable. (Bunch of problems/bugs in v4.0.0)

luciodra wrote: 10 Apr 2026 08:28 What are they called and where can you find these "metal brackets" that are used to better block the chips in the socket?

Retention clips. I asked a bunch of people over the years. No one else seems to have come across them, that I can find.

Ok.

Mikerochip wrote: 15 Apr 2026 15:29 PiGUS v4.1.0 out. And, now considered stable. (Bunch of problems/bugs in v4.0.0)

I cannot see a new firmware released yet and the changes only show updates to version numbers for the firmware (not yet released) and PGUSINIT which is just a version change (no changes otherwise).

kodak80 wrote: 16 Apr 2026 09:04

Mikerochip wrote: 15 Apr 2026 15:29 PiGUS v4.1.0 out. And, now considered stable. (Bunch of problems/bugs in v4.0.0)

I cannot see a new firmware released yet and the changes only show updates to version numbers for the firmware (not yet released) and PGUSINIT which is just a version change (no changes otherwise).

Yeah, same, sorry. I was on the authors BluSky page, and he said "v4.1.0 released", so, I just assumed...

Mikerochip wrote: 16 Apr 2026 09:22

kodak80 wrote: 16 Apr 2026 09:04

I cannot see a new firmware released yet and the changes only show updates to version numbers for the firmware (not yet released) and PGUSINIT which is just a version change (no changes otherwise).

Yeah, same, sorry. I was on the authors BluSky page, and he said "v4.1.0 released", so, I just assumed...

Actually, you were correct, I dug into the commits this morning and there are indeed some code updates to PGUSINIT addressing bugs. I have copied these updates over and spun up a new 3.9.0a PRG version. The source also contained code I had added, so now aligns to the original source code again.

EDIT: I have successfully flashed v4.0.0 firmware to my PicoGUS v2.0 using this version. It was slow but worked.

Not sure how the new Soundblaster options work such as /SBTYPE to switch?

Looks like they pulled the v4.1.0 firmware as it was broken.

kodak80 wrote: 17 Apr 2026 07:06

Raven060 pgusinit-3.9.0a (for use with firmware 4.1.0).7z

Pgusinit seems to work, but firmware 4.1.0 still crashes on Raven...

luciodra wrote: 20 Apr 2026 07:40 Pgusinit seems to work, but firmware 4.1.0 still crashes on Raven...

The 4.1.0 release of the firmware was removed as it had some severe issues, so would probably be better to stick with 4.0.0 and wait for the next release.

luciodra wrote: 20 Apr 2026 07:40

kodak80 wrote: 17 Apr 2026 07:06

Raven060 pgusinit-3.9.0a (for use with firmware 4.1.0).7z

Pgusinit seems to work, but firmware 4.1.0 still crashes on Raven...

firmware 4.1.0 was pulled as it had too many bugs. It is no longer available on the PicoGUS Github releases. v4.0.0 is the latest stable firmware at the moment. There are ongoing updates being done on the PicoGUS code which I am currently monitoring. All PGUSINIT updates have been done so far and are in Raven060 pgusinit-3.9.0a

Kicad inspiration struck.
The revA1 on the right is starting to look more and more empty in comparison :)

!

What have you added?
USB keyb/mouse...
What else? :P

yes, mainly smaller things;
- usb keyb/mouse
- sotware controlled volume for the ym output
- small amp and header for internal speaker
(mute control is Falcon compatible)
- ide port is now big endian
- pwm fan control
- argb lighting header
- and misc other minor things


The biggest change and what takes most space is the added DSP, and the RAM for it.
Which is not mandatory and the computer should work fine without it soldered.

For now, I've routed its two ESSI ports to one internal header each
That part is not set in stone but I don't know exactly what I want to do with them so this would provide an easy way to experiment.

One ESSI could for example be an I2S audio in+out, or provide three individual SPI ports.
Or something else entierly but realistically that's probably how you'd want to use them.

If I were to 'hardwire' it I on the board I would probably do something like that:
One SPI controlled codec for audi in + out, and then two SPI headers for playing around with random SPI modules (wifi perhaps?)

OpenOCD has support for its Jtag/OnCE debugger interface so that's on a header too.