Jasmin time

If you want to ask questions about how the machine works, peculiar details, the differences between models, here it is !
How to program the oric hardware (VIA, FDC, ...) is also welcome.
User avatar
Dbug
Site Admin
Posts: 3211
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Jasmin time

Post by Dbug » Thu Jan 09, 2020 7:51 pm

iss wrote:
Thu Jan 09, 2020 6:08 pm
what you read from status/data registers depends on alignment of some addresses :shock: . I'm
That sounds like the Telestrat microdisc alignment bug... I hate this crap!

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Thu Jan 09, 2020 10:17 pm

After almost one month of 24/7 hard fight with Jasmin I can say that I'm really(!) close to finish this project ... surprisingly with success! :)

Here is a story about the last issue I hit (sorry for the number of videos):
From the very beginning of my work I prepared some demos with series of sample pictures for debugging and testing how the source works. After I rewrote the sources 3 or 4 times from zero, using different approaches - every time I was ending with strange error statuses from the FDC which lead to freezes in demos. At end I decide to disassemble and use FT-DOS reading routine which reads data with IRQ - just to have basis to compare with my code and ... surprise, surprise it failed just like my code:

Jasmin reading tracks with polling:

Jasmin reading tracks with IRQ:

After many, many experiments I found that if I mask some bits from the pictures then no freezes and errors appear, and everything runs (relatively) fast and smooth:

Jasmin reading tracks with polling and masks bits:

Jasmin reading tracks with IRQ and masks bits:

With many (more) tests and brain-storming the result is headache but the conclusion is:

If we have more than 32 bytes with more than 5 bits set on random places but in the range: 0x9900...0xBFDF then Jasmin FDC starts to return error codes (Bad CRC / Recored not found) and corrupt data!

Here is one more video - it runs under FT-DOS and uses simple BASIC program which can be seen at the start of the clip. The BASIC program first fills the range 0x6000..0x7F67 with value of 0x7F (7 bits are set(!)).
Use RUN200 to save above range to a file.
Use RUN300 to switch in HIRES and load the saved file at address 0xA000.

Every time FT-DOS fails to load complete HIRES screen:

So, Jasmin owners are wanted for testing - there will be reward!
I need help to find if this problem is only with my Jasmin or it occurs with other Jasmin controllers too.
Attached are all images used for tests!

PS. @Dbug: yes, it's the same alignment bug but the things are bit different - I think there is bug in Fabrice's bug fix!!! 8)

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Thu Jan 09, 2020 10:32 pm

Here is the copy loop which copies the loaded picture from memory buffer at 0x8000 to video memory at 0xA000:

Code: Select all

; --------------------------------------------------------------------------------
pic_blit      ldy   #$00
              sty   p_src
              sty   p_dst
              lda   #>$8000
              sta   p_src+1
              lda   #>$a000
              sta   p_dst+1
              ldx   #$10
blit_loop     lda   (p_src),y
;             and   #%01010111    ; FIXME: magic - mask 3 bits and ... it works!
              and   #%11111111    ; else we got lot of errors CRC/Record not found
              sta   (p_dst),y
              iny
              bne   blit_loop
              inc   p_src+1
              inc   p_dst+1
              dex
              bne   blit_loop
              rts
You can see if we use mask #$FF (i.e. puting picture "as is" in the video) then we got errors, if we mask randomly some bits limiting byte to have no more than 5 bits set then no errors occur.

You can compare binary attached DSK images - you will find only 2 differences 1 byte internal check sum and the changed byte 0xFF -> 0x57.
dsk-images-for-testing.zip
(72.49 KiB) Downloaded 18 times

User avatar
Chema
Game master
Posts: 2571
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Jasmin time

Post by Chema » Thu Jan 09, 2020 11:45 pm

More probably a bug in my patch trying to adapt Fabrice's patch... :)

But what is the relation between the bits set to one in data and the alignment of instructions? Maybe I need to read your messages more carefully...

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Fri Jan 10, 2020 1:11 am

Chema wrote:
Thu Jan 09, 2020 11:45 pm
Maybe I need to read your messages more carefully...
@Chema; Please, do it, your opinion is important for me, honestly :!:

Above problem is not related to any alignment. My (thanks to jorodr's) Jasmin controller is most probably faulty. Something happens with the data bus and WD1770 starts to behave strange when in the memory range 0x9900..0xBFFF (where all video stuff happens) are bytes with more than 5 bits set. As result you can't: define characters, read data from floppy directly to video memory, etc. I need to know if other Jasmin controllers are working like mine. Testing is easy use the attached above DSK images and give feedback what works or not. IMO this test is important because if only my drive is faulty then everything is fine, source works, I'll simply repair my drive and all are happy! But if there are other drives with the same symptoms then case is bit different - I can't be sure that my sources are 100% Jasmin compatible and reliable which makes them bit useless - that's the point. Also if there is a hardware fix how many Jasmin owners will eventually apply it to their drives too?
Anyway, I'll be very thankful if someone do the test!

christian
Pilot Officer
Posts: 83
Joined: Sun Nov 24, 2013 9:58 pm

Re: Jasmin time

Post by christian » Fri Jan 10, 2020 12:04 pm

I do not remember ever having encountered this problem with my Jasmin.
Do you have the same problem within other address ranges?

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Fri Jan 10, 2020 12:56 pm

christian wrote:
Fri Jan 10, 2020 12:04 pm
I do not remember ever having encountered this problem with my Jasmin.
Do you have the same problem within other address ranges?
No, I've tested every page as read buffer and it works i.e. no problems at 0x0200-0x02FF, 0x0400...0x8FFF and even 0xC000...0xFFFF with RAM overlay enabled.

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Wed Jan 22, 2020 12:17 am

Well, good news!
Jasmin reads tracks error free with polling:

Jasmin reads tracks with polling and writes them back with IRQ - error free!

After spending lot of time with the annoying errors (bad status read from the FDC if video related memory contains bytes with more than 5 bits set) from previous video I decide to study the hardware closely (read: with the soldering iron ;)).
Both ribbon cables replaced with 34-pins headers because they were crimped to IDC34-PCB-Mount type and WD1770 set on socket. Also power wires changed with more thicker and buttons replaced with new:
jasmin-upgrade.jpg
jasmin-upgrade.jpg (1.16 MiB) Viewed 1538 times
As you can see I used a C64 1581 floppy drive as donor for WD1772 to have spare for more tests (btw, the 1581 is brand new but I already dedicated it to Oric because the floppy inside a Chinon is real beast - it reads everything :!:).
After some tests I found that the root of the errors is the ribbon cable between Oric and Jasmin - when it's shorter than 15cm - everything works like a dream and no more interference with the video memory content!
That being said, I wonder how the Jasmin was working at all with the original ribbon cable which length is exactly 70cm?
For me such problem can be really expected because Jasmin controller doesn't have any buffers (i.e. no 'LS245, 'LS244).

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Wed Jan 22, 2020 12:55 am

Here attached is the DSK image used in the read/write test.
Now the next annoyance is why the reading with polling is OK but the writing always fails with error status 0x04 - LOST DATA, which means writing loop is late to supply next byte. The strange thing here is that the code is exactly the same as the reading code. Of course the only difference is:

Code: Select all

reading:
    lda from_fdc_data
    sta to_memory,y
    
writing:
   lda from_memory,y
   sta to_fdc_data
The cycles in the loops are 26 when the new byte should be put in the register every ~31.5 microsecs...
The code is properly aligned i.e. no page crossing... Don't hesitate to give ideas what to look for!

But if we go back to the primary goal of this whole story which is: to have working solution for all types floppy controllers and disks then: How bad will to use IRQ's for writing only? The only drawback I see is that during the short saving of the "high score table" there will be no background music :D
Attachments
rw-test.dsk.zip
(18.81 KiB) Downloaded 20 times

User avatar
Dbug
Site Admin
Posts: 3211
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Jasmin time

Post by Dbug » Wed Jan 22, 2020 6:22 pm

iss wrote:
Wed Jan 22, 2020 12:55 am
But if we go back to the primary goal of this whole story which is: to have working solution for all types floppy controllers and disks then: How bad will to use IRQ's for writing only? The only drawback I see is that during the short saving of the "high score table" there will be no background music :D
A reliable save sounds important, even if it's slower, and in any case, you would want people to not do things like eject the floppy while writing, so it's really a special case :)

ThomH
Flying Officer
Posts: 204
Joined: Thu Oct 13, 2016 9:55 pm

Re: Jasmin time

Post by ThomH » Wed Jan 22, 2020 11:46 pm

Have you tested the clock signal on the Jasmin? Just as a random guess, but has it possibly drifted into overclocking territory?

That'd directly affect the speed it wanted data when writing, but might not be sufficiently far to cause an issue when reading.

I guess you could also read track after writing and (usually) be able to check whether the new version of the sector is followed by a tail of the old version of the sector.

Of course, I don't know how tightly coupled your write loop is to the expected output bit rate. So maybe this guess is nonsense.

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Sat Jan 25, 2020 3:32 pm

ThomH wrote:
Wed Jan 22, 2020 11:46 pm
Have you tested the clock signal on the Jasmin?
The clock is 8MHz with acceptable tolerance, not very good looking but here the oscilloscope is to be blamed:
8mhz.png
8mhz.png (14.02 KiB) Viewed 1431 times
More important there is definitely a drift between 8MHz clock and the 1MHz F2 signal i.e. the phase difference is not constant.
One curious detail is that LOST DATA is asserted exactly after 128 bytes are read with no problem. I'm using only sectors with 256 bytes and in very very rare cases this number riches 129 or even 130. The only explanation for this results is that there is kind of delay which accumulates and the polling code can't react on time after 128 loops. As indirect proof for this is the routine which uses IRQ - the synchronization is done on every new byte and it's rock solid and works really stable.

Now I'm very close to the decision to use IRQ for Jasmin and polling for Microdisc! So far the "price" for having 2 types of read/write routines is about 128 bytes in code length - IMO absolutely acceptable, of course one can optimize it easily and discard the unused part.

christian
Pilot Officer
Posts: 83
Joined: Sun Nov 24, 2013 9:58 pm

Re: Jasmin time

Post by christian » Sat Jan 25, 2020 4:56 pm

FTDOS use always IRQ to read or write data

User avatar
Dbug
Site Admin
Posts: 3211
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Jasmin time

Post by Dbug » Sun Jan 26, 2020 10:19 am

iss wrote:
Sat Jan 25, 2020 3:32 pm
More important there is definitely a drift between 8MHz clock and the 1MHz F2 signal i.e.(...) The only explanation for this results is that there is kind of delay which accumulates and the polling code can't react on time after 128 loops.
Was that tested with only one Oric and one Microdisc or Jasmin unit?

I remember Oric was doing some surgery on machines when they were having issues, maybe they simply tried to find matching crystals to limit problems of desync between the Oric and the paired disk drive?

User avatar
iss
Squad Leader
Posts: 993
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Jasmin time

Post by iss » Sun Jan 26, 2020 2:36 pm

Dbug wrote:
Sun Jan 26, 2020 10:19 am
Was that tested with only one Oric and one Microdisc or Jasmin unit?
I'm using 4 Orics in the test and only 1 Jasmin drive. There is no difference when changing the Oric and I consider this as stable basis to search the issues in the Jasmin only. Else the quartz looks old but nice:
quartz-8Mhz.jpg
quartz-8Mhz.jpg (283.06 KiB) Viewed 1379 times
BTW, you can see the PCB's quality is bad - only the bottom (solder) side has soldering mask and I really try to avoid surgeries when not needed (I already replaced 2x34 connectors and 1x28 pin chip which is actually a proof for the opposite :)). And IMO the main goal is to have working code on any Jasmin not only on mine.
Additionally, to read/write a sector we need 256(bytes) x 32(uS) = 8192(uS) = 8.2 (mS), so we have remaining 12(mS) to play a mym frame - IMO it will be enough just need to be confirmed by experiment :).

Post Reply