Another PiStorm Blog

Blogs & guides and tales of woo by forum members.
User avatar
exxos
Site Admin
Site Admin
Posts: 24061
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Another PiStorm Blog

Post by exxos »

stephen_usher wrote: Sun May 12, 2024 12:01 pm There's a new Github branch of the code now: https://github.com/gotaproblem/pistorm- ... ee/may2024
Cool.

Might not get time this week to do anything again though. A lot going on in and out of Atari world.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
stephen_usher
Posts: 5799
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

I know what you mean. I've put this on the back burner this week as I'm finishing the preparations for the Portables exhibition event in Cambridge next weekend.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
Badwolf
Posts: 2280
Joined: Tue Nov 19, 2019 12:09 pm

Re: Another PiStorm Blog

Post by Badwolf »

stephen_usher wrote: Sat May 11, 2024 2:20 pm OK, implemented that change, though 0x1FFD is not correct, I'm using 0xFF00 as anything else fails to go get out of the loop.

The value of l is usually 0xd9xxxx6c or 0xd9xxxx7c. The xxxx values are usually 0x0000 but often 0xffff and sometimes other values such as 0x4001, 0x4081, 0x7fef or 0x5bef.
Hmm, I must be misremembering what gpio[13] returns as it looks like l is 32 bits and shifted right 8 at the end to get the status.

I was assuming I was masking the 16 bits being passed from the verilog.

My mask probably needs to apply to the shifted, truncated result rather than the native 32 bit l, in that case.

So perhaps something more like

Code: Select all

inline
uint16_t ps_read_status_reg () 
{
  static uint32_t l;
  static uint16_t status;

do {

  while ( gpio [13] & 1 );

  gpio [7] = 0x4C; //(REG_STATUS << PIN_A0) | (1 << PIN_RD);

  while ( gpio [13] & 1 );

  l = gpio [13];
  status = ( l >> 8 );

  gpio [10] = TXN_END;
  
}while ( (status & 0x1FFD) != 0 );

  return status;
}
?

But I'd still prefer to use the 'original' status getting code for starters.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
stephen_usher
Posts: 5799
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

The latest emulator code just checks for an invalid status, prints an error message and then ignores the status as a workaround.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
stephen_usher
Posts: 5799
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

Some new firmware and emulator binaries turned up on Friday but due to other commitments I've only had a chance to test them today.

Well, on a positive note I can get to the TOS 1.04 desktop... But the emulation crashes as soon as I double click on a drive icon.

The new firmware doesn't seem to map local ROM images, so it's booting from the on-board ROMs. I also had to decrease the GPIO clock even further down to 68MHz. Any more or less than that made it totally unstable.

It feels to me that the first thing that needs sorting out is the communication between the CPLD and the Raspberry Pi. Unless this is rock solid you're trying to fight on multiple fronts and the project won't get anywhere.

I also wonder if the CPLD part fitted by the board manufacturer is genuine and not a rebadged slower part.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
Post Reply

Return to “MEMBER BLOGS”