1 Topic by macca

  • macca
  • esxDOS User
  • Offline
  • Registered: 2019-03-13
  • Posts: 10

Topic: Hardware test program

Hi,

I'm experiencing some problems using a DivMMC Future board with EsxDOS 0.8.7, sometimes it won't load the SD card directory, other times it hangs (even the reset button won't work). I'm not sure what kind of operations causes these problems, the last time I was just using the .tapeout command to set a file and save a basic program, the file was saved correctly but after that the NMI handler wasn't working anymore.

A power on/off cycle fixes it but is weird, I don't remember it happened in the past, I fear I have somehow damanged the board so I was wondering if there is a test program that can verify the onboard ram and peripherals ?

Best regards,
Marco

2 Reply by Luzie (edited by Luzie 2020-04-11 11:24:27)

  • Luzie
  • esxDOS Guru
  • Offline
  • Registered: 2013-09-26
  • Posts: 384

Re: Hardware test program

I just know of:
"DIVRAMKA (2017-12-09) - new tester utility for test sram memory in DivIDE / DivMMC interface (full capacity 8 - 512kB)"
which can be found at: https://velesoft.speccy.cz/zx/divide/divide-soft.htm

But have you already tested with another memory card or freshly formatted your SD-Card? Most time it´s a problem within the file-system on the card or the SD-Card not fully working with the Interface.

3 Reply by macca (edited by macca 2020-04-15 08:57:34)

  • macca
  • esxDOS User
  • Offline
  • Registered: 2019-03-13
  • Posts: 10

Re: Hardware test program

Awesome thanks!

I ran the test few times and the ram seems good so far, and in the last couple of days I haven't had any issue, I don't think it is the SD card but I'll try others.

I start to think that maybe I did something weird that corrupted the ram somehow, I was using tapein / tapeout commands, rm to delete temporary tap files, some folders on the SD contains a lot of files, maybe there is a limit on that ?

I also saved and loaded programs from a real tape, do you know if there are issues when a DivMMC board is connected ?

4 Reply by Luzie

  • Luzie
  • esxDOS Guru
  • Offline
  • Registered: 2013-09-26
  • Posts: 384

Re: Hardware test program

macca wrote:

I also saved and loaded programs from a real tape, do you know if there are issues when a DivMMC board is connected ?

No, I never read or heard about problems with this.

5 Reply by Spezzi63 (edited by Spezzi63 2020-04-15 21:27:56)

  • Spezzi63
  • esxDOS Fan
  • Offline
  • Registered: 2016-03-18
  • Posts: 69

Re: Hardware test program

Hi,
ok, I don't have a DivMMC Future, but maybe some information will help. From the hip only:

1. Access error: A file could be in use (?)
-------------------------------------------------- ---------------------------
https://www.thefuturewas8bit.com/divmmc-future-guide
Saving files
......
Your program will then be written out to the filename.tap file. If you want to change files or load back, you should use the following command the close the file.

.tapeout –c filename.tap
-------------------------------------------------- ---------------------------
2.
To load real tape it helps to discharge the Virtual Tape slot before.

3.
and another old info:
Please note that a maximum of 704 files per folder is supported.
When having more files than that, split the file-set in subfolders.

Regards,
Günter

6 Reply by macca

  • macca
  • esxDOS User
  • Offline
  • Registered: 2019-03-13
  • Posts: 10

Re: Hardware test program

I think I got a way to reproduce the error:

Turn on the Spectrum and type a simple basic program (10 PRINT "Hello" should be enough), then type the commands:

.tapeout tape01.tap
SAVE "hello"
.tapeout -c
SAVE "hello"

The second SAVE after closing the tapeout will save to a real tape deck (no need to have one).

Now press the NMI button, the first time the browser should open correctly, exit pressing SPACE and press the NMI button again, now the program should display a blank screen. Exit with SPACE seems to work but a tone is played.

This is reproducible even with the Fuse emulator and apparently it affects only the NMI handler because all dot commands seems to work correctly even if the handler crashes. And also apparently it is a bug in version 0.8.7, version 0.8.6 seems to work at least with the emulator, I need to downgrade the DivMMC future to test on a real Spectrum.

7 Reply by macca

  • macca
  • esxDOS User
  • Offline
  • Registered: 2019-03-13
  • Posts: 10

Re: Hardware test program

After some more testings, looks that saving to tap is bugged.

Just do:

.tapeout tape.tap
SAVE "program"

Press the NMI button and crashes.

Downgraded to EsxDOS 0.8.6 and all seems to work correctly, will stick with that for time being.

8 Reply by Luzie

  • Luzie
  • esxDOS Guru
  • Offline
  • Registered: 2013-09-26
  • Posts: 384

Re: Hardware test program

macca wrote:

After some more testings, looks that saving to tap is bugged.

Just do:

.tapeout tape.tap
SAVE "program"

Press the NMI button and crashes.

Downgraded to EsxDOS 0.8.6 and all seems to work correctly, will stick with that for time being.

Great Finding. I´m sure Miguel will have a look into it when he discovers your posts.

9 Reply by lordcoxis

  • lordcoxis
  • Administrator
  • Offline
  • Registered: 2013-07-03
  • Posts: 101

Re: Hardware test program

macca wrote:

After some more testings, looks that saving to tap is bugged.

Just do:

.tapeout tape.tap
SAVE "program"

Press the NMI button and crashes.

Can't replicate this on v0.8.8 so I'll assume it's some weird bug on v0.8.7. When you do the SAVE, what program do you have in memory?

Thanks

lordcoxis's Website

10 Reply by macca

  • macca
  • esxDOS User
  • Offline
  • Registered: 2019-03-13
  • Posts: 10

Re: Hardware test program

lordcoxis wrote:

When you do the SAVE, what program do you have in memory?

Only a BASIC program, like 10 PRINT "Hello" is enough.
Sometimes it is necessary to trigger the NMI two times to see the error (the first works, the second crashes). I believe it may have to do with the size of the basic program or the variables it uses. All tests were made after power-on without doing anything other than typing the program and commands.

Also only the NMI handler seems to be affected, so far all dot commands, including tapein/out SAVE/LOAD are working even after the handler crashes (provided you are able to return to basic, of course).