Sedoric's TAKE command, help required...

This is the best place to discuss about the various Oric operating systems like Sedoric, Randos, FT-Dos, and others.
Post Reply
omelette
Officer Cadet
Posts: 60
Joined: Wed Mar 10, 2010 9:54 am

Sedoric's TAKE command, help required...

Post by omelette » Mon Dec 23, 2019 12:08 am

Hi. I'm trying to use Sedoric's TAKE command but am running into difficulties. I issue an OPEN D,1, followed by a TAKE 1,0,1,A - this should load T0, S1 of drive A into the 'buffer'. Thing is, I cannot find this infernal buffer! I felt sure it was in ram overlay,somewhere from $c000 -> $c3fff, but when I do a MOVE #c000,#d000,#1000 and inspect what I've just copied from ram overlay, I don't find the buffered sector.

Can anyone tell me where I'm going wrong?

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

Re: Sedoric's TAKE command, help required...

Post by iss » Mon Dec 23, 2019 2:14 am

open-take-deek.png
open-take-deek.png (29.31 KiB) Viewed 444 times
After TAKE, use DEEK(2) to find the buffer address.
Why and how to force user specific buffer for TAKE command - I dunno :)
This works for Sedoric2 and Sedoric3.

omelette
Officer Cadet
Posts: 60
Joined: Wed Mar 10, 2010 9:54 am

Re: Sedoric's TAKE command, help required...

Post by omelette » Tue Dec 24, 2019 6:04 pm

Excellent! So not in ram-overlay after all, wonder where i got that notion from. Just knowing where it is, is all I require, as I can then MOVE it where ever I want. Thanks for that.

omelette
Officer Cadet
Posts: 60
Joined: Wed Mar 10, 2010 9:54 am

Re: Sedoric's TAKE command, help required...

Post by omelette » Mon Jan 13, 2020 12:52 am

Question, is there a list of bugs still 'resident' in the various flavours of Sedoric available somewhere?

I've spent a fair amount of time playing with the TAKE command, and gotta admit that it seems pretty useless when used in a program! The problem is that the TAKE's disk-buffer resides in the Oric's variables area, and whenever the OS does a 'garbage collection' of variables in use by the program, it shifts the disk-buffers location in ram also, often by as much as 10-30 bytes. This means that the location held in address 2 (DEEK(2)) is no longer current when this 'shift' occurs. Try to outfox it 'programatically' and its position seems to jump about even more.

This is compounded by a bug I discovered in the MOVE command. MOVE #1000, #10FF, #2000 works as expected - it copies 255 (not 256) bytes from #1000 to #2000. However, a MOVE #1000, #1100, #2000, copies not the expected 256 bytes, but 512 bytes!!! This action was overwriting variables used by my program, producing all manner of weird error messages. I think I checked all of the versions of Sedoric that I have and it exists in ALL of them, which begs the questions, how could this have been missed, and why has it never been removed?

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

Re: Sedoric's TAKE command, help required...

Post by iss » Mon Jan 13, 2020 1:42 am

About the buffers you can protect them from BASIC with HIMEM#ADDRESS where ADDRESS is set just bellow the buffers.
But this is bit ugly and it's possible that your program goes 'OUT OF MEMORY'. Well, it would be very helpful if someone with more knowledge in Sedoric internals shares how to set the buffer address for TAKE command, else I can try to debug it deeper as soon as I have some free time.

User avatar
mikeb
Flying Officer
Posts: 156
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: Sedoric's TAKE command, help required...

Post by mikeb » Mon Jan 13, 2020 6:26 pm

omelette wrote:
Mon Jan 13, 2020 12:52 am
how could this have been missed, and why has it never been removed?
Sounds like an off-by-one error in dealing with the fact you've overshot 255->256 bytes, and the maths has compensated twice somewhere (as simple as a carry-bit set when ALSO adding 1 to the High byte, e.g.)

Things like that are missed because testing is boring. Thinking up all the weird and wonderful cases for e.g. a memory copy, then checking each one does exactly what you want *and no more*, is boring :)

Copy 0 bytes (start=end), copy 1 bytes, 2 bytes, assume up to 254 is probably ok, try 255, 256?, 257, skip along a bit ... what about destination address is the same as start, is just-less than start (so buffers are overlapping), really-less than start (non overlapping), same for end addresses, what about start address is close to top of memory and length would wrap around. Aaaah ... :)

How did the 6502 designers miss the bug where addresses wrap around incorrectly (due to NOT incrementing the high byte) where things straddle a page boundary (effectively reading 0x5FF and 0x600 really reads 0x5FF and 0x500) ? :)

User avatar
ibisum
Wing Commander
Posts: 1180
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Sedoric's TAKE command, help required...

Post by ibisum » Mon Jan 13, 2020 6:54 pm

>How did the 6502 designers miss the bug where addresses wrap around incorrectly (due to NOT incrementing the high byte) where things straddle a page boundary (effectively reading 0x5FF and 0x600 really reads 0x5FF and 0x500) ? :)

Isn't this a feature - e.g. you might use it with zero-page shadow mapping somehow?

User avatar
Symoon
Archivist
Posts: 1804
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Sedoric's TAKE command, help required...

Post by Symoon » Mon Jan 13, 2020 9:48 pm

From Sedoric à nu, here is the code where the amount of pages/bytes is calculated for the command MOVE in Sedoric 3.
I'm too tired to check if it's correct or not, especially if a SEC isn't missing. I'll let you guys do ;)
With #1000 and #1100 if I'm not mistaken, according to the command doc, we should have a full page and zero remaining bytes to copy (00-FF, the end parameter being excluded).

NOTE: the adresses are for instance C771a, where a means "1st bank loaded".

Code: Select all

Calcule le nombre de pages entières à transférer

C771a 08       PHP         sauvegarde les indicateurs 6502
C772a 78       SEI         interdit les interruptions
C773a 38       SEC
C774a A5 F4    LDA F4      calcule:
C776a E5 F2    SBC F2      YX = F4/F5 - F2/F3 = LNGBLOC longueur du bloc
C778a A8       TAY         ou X = HH est le nombre de pages entières
C779a A5 F5    LDA F5      et Y le nombre d'octets de la page incomplète
C77Ba E5 F3    SBC F3
C77Da AA       TAX
C77Ea 90 48    BCC C7C8    erreur si FINBLOC < DEBBLOC (LNGBLOC négatif)
C780a 86 F9    STX F9      F9 = nombre de pages entières à transférer
If the bug is not located here, then it's maybe in the transfer commands a bit further.
Sedoric à Nu doesn't talk about a bug here it seems, it might be worth taking a look in CEO-Mags if it hasn't been spotted later - but apart from the coding of Sedoric 4 by Michel, I don't think much has been done on it since 1998 (Sedoric à Nu release date).

omelette
Officer Cadet
Posts: 60
Joined: Wed Mar 10, 2010 9:54 am

Re: Sedoric's TAKE command, help required...

Post by omelette » Tue Jan 14, 2020 12:12 am

iss wrote:
Mon Jan 13, 2020 1:42 am
About the buffers you can protect them from BASIC with HIMEM#ADDRESS where ADDRESS is set just bellow the buffers.
But this is bit ugly and it's possible that your program goes 'OUT OF MEMORY'. Well, it would be very helpful if someone with more knowledge in Sedoric internals shares how to set the buffer address for TAKE command, else I can try to debug it deeper as soon as I have some free time.
Well, I had already tried that and I got an immediate 'out of memory' error. I've just tried first creating numerous string (70+ chars in each one) variables first in my program, then deleting them, in the hope that this 'freed memory' would be enough for the rest of the program's variables needs - I still get the 'out of memory' error after one print statement is executed. Doing this saw the buffer-address in #2 take a big jump, but nowhere near what I was expecting - only around 40 bytes, versus the 300+ bytes the strings occupied. And it moved 'up' in memory, as opposed to going down like I was expecting!

omelette
Officer Cadet
Posts: 60
Joined: Wed Mar 10, 2010 9:54 am

Re: Sedoric's TAKE command, help required...

Post by omelette » Tue Jan 14, 2020 12:40 am

mikeb wrote:
Mon Jan 13, 2020 6:26 pm
omelette wrote:
Mon Jan 13, 2020 12:52 am
how could this have been missed, and why has it never been removed?
Things like that are missed because testing is boring. Thinking up all the weird and wonderful cases for e.g. a memory copy, then checking each one does exactly what you want *and no more*, is boring :)
Bugs don't surprise me. It's the amount of time that has elapsed since Sedoric v1.0 first launched, and the bug still exists, even in version 4, that surprises me! :) This was the reason I asked was there a bug-list for Sedoric available somewhere, as it would be comforting to at least know that I wasn't the first to spot it. I've just tried running Oricutron to see if the bug is being emulated as well. Unfortunately, Oricutron crashes on my setup with the least provocation, and loading from Sedoric (the Orion ass/diss. in this instance) stops it dead.

User avatar
mikeb
Flying Officer
Posts: 156
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: Sedoric's TAKE command, help required...

Post by mikeb » Tue Jan 14, 2020 7:08 pm

ibisum wrote:
Mon Jan 13, 2020 6:54 pm
>How did the 6502 designers miss the bug where addresses wrap around incorrectly (due to NOT incrementing the high byte) where things straddle a page boundary (effectively reading 0x5FF and 0x600 really reads 0x5FF and 0x500) ? :)

Isn't this a feature - e.g. you might use it with zero-page shadow mapping somehow?
I believe if it was a feature (not a bug) it would be documented as such in 6502 manuals/data sheets, maybe with an example of why it was useful.

However, every reference I've ever seen to it is when something goes wrong -- it's easy for some working and tested assembly code to mysteriously break down when a few new instructions shuffle things along, and the location of a pointer etc. suddenly crosses a page boundary ... nasty to find.

I'm not sure if it was fixed in later 65X02 revisions, or exists in 65XX instruction set compatible processors, but fixing things like that can be worse than knowing the bug is there and working round it (fixes on top of fixes) :)

Post Reply