AspeQt: Yet another SIO2PC/APE clone

[flashjazzcat]

Anyone? This is a usability question, btw... so I'm not going to raise a ticket for it - at least not until I know it's a bug / feature request.

[atari8warez]

Since there are no options in the menu or in the settings screen, I would say there is no way to stop printer emulation or change the monitored printer port(s). I know I haven't added such options since I started working with AspeQt and I never felt a need to do so as I don't print from Ataris. I do admit however AspeQt should be able to stop/start printer emulation or monitor printer ports selectively. Whether it's considered a bug or a feature request doesn't matter just file it the way you see appropriate.

 

I am not coding during summer (too many other possibilities outdoors during the sun season - a major one for me is boating) but will come back to it probably after September.

[flashjazzcat]

OK - thanks for the reply Ray.

[GoodByteXL]

I am not coding during summer (too many other possibilities outdoors during the sun season - a major one for me is boating) but will come back to it probably after September.

Hey, when having survived summer please think about printer options to do graphic printouts. Would be a nice christmas present.

 

Thereafter I'll be away with our camper to the South, surviving the winter :-)

[FULS]

I am not coding during summer (too many other possibilities outdoors during the sun season - a major one for me is boating) but will come back to it probably after September.

Thank You for taking over and continuing this project. I can't imagine how many hours of your time you've put into these updates, with no compensation. AspeQt has evolved into a top notch program. AspeQt and Altirra are such useful utility's that I use daily in this hobby.

 

Thank You!

[atari8warez]

Hey, when having survived summer please think about printer options to do graphic printouts. Would be a nice christmas present.

 

Thereafter I'll be away with our camper to the South, surviving the winter :-)

 

I would like to, the only problem I don't have one of those printers to test it with, but I'll see what I can do.

[atari8warez]

Thank You for taking over and continuing this project. I can't imagine how many hours of your time you've put into these updates, with no compensation. AspeQt has evolved into a top notch program. AspeQt and Altirra are such useful utility's that I use daily in this hobby.

 

Thank You!

 

Thank you for the kind comments. I indeed spent a lot of time not only deciphering existing AspeQt code but also learning the Qt, Qt IDE and C++ programming. I am still not with any stretch of imagination a C++ or Qt expert but every new feature I add or enhance helps me get there slowly. As I learn more I am hoping to speed up development and be able to add more features in the coming months/years...

Edited August 29, 2013 by atari8warez

[lemiel]

I had just add ticket about Turbo 1050 mode.

Why I need it? To have fast copying from/to real drive with extension enabled to work in this Turbo mode to/from image on PC.

 

(I know, this is worst turbo, but fast and some people got only it, and when Atari is enabled with it it can only work with turbo enabled drives.)

[atari8warez]

if i understand this request correctly, all you need to do to use 1050 Turbo mod is to use a compatible DOS/OS when running AspeQt. Hias's HighSpeed OS and/or SDX should support 1050 Turbo mode (not sure about SpartaDos/MyDos), AspeQt has no control over real disk drive access. AspeQt supports high speed only in virtual drives, up to 125,000bps (Pokey Divisor 0) over the serial port.

Edited August 31, 2013 by atari8warez

[GoodByteXL]

I had just add ticket about Turbo 1050 mode.

Why I need it? To have fast copying from/to real drive with extension enabled to work in this Turbo mode to/from image on PC.

 

(I know, this is worst turbo, but fast and some people got only it, and when Atari is enabled with it it can only work with turbo enabled drives.)

Turbo mode is an issue of accessing real floppy disk drives and there are two different systems I know of: 1050 Turbo from B. Engl and TOMS Turbo. Both are special hardware speeders built-in into real drives. I guess this is not the question here?

 

if i understand this request correctly, all you need to do to use 1050 Turbo mod is to use a compatible DOS/OS when running AspeQt. Hias's HighSpeed OS and/or SDX should support 1050 Turbo mode (not sure about SpartaDos/MyDos), AspeQt has no control over real disk drive access. AspeQt supports high speed only in virtual drives, up to 125,000bps (Pokey Divisor 0) over the serial port.

There are quite some different OS supporting high speed access to AspeQt's virtual disk drives. When using an original ATARI OS for compatibility reasons SpartaDOS X V. 4.4x is the choice, since it supports here in the cartridge version pokey divisor 3 with an FT232R-based SIO2PC(USB) connection and divisor 0 using an IDEplus.

 

What is an issue is copying from/to real floppydisk drives using a turbo enhanced floppy disk drive and AspeQt. I guess this is what you are asking about? If so I I'd support this request!

 

Unfortunately this is not solvable with AspeQt but partly using SDX V. 4.4x. A snippet from the manual:

 

CAUTION: The formatter uses the 6502 stack space intensively. Because of that, some

floppy disk drive turbo systems, which load the fast serial I/O patch onto the stack, will

not work in turbo mode. Problems will occur with 1050 Turbo, Top Drive 1050, TOMS

Turbo Drive or any other using the same method. Such a drive can be used with

SpartaDOS X, but only at the standard baud rate.

 

Other speeder systems, such as TOMS Multi Drive (in the Ultra Speed mode), TOMS

710/720, CA-2001, ATARI XF551, LDW Super 2000, Indus GT, Happy, 1050 US Doubler –

will work normally.

 

Other Notes: More high speed disk drives tested successfully are XF551 with HyperXF

ROM, HDI, 1050 Speedy (all versions).

 

Rana 1000, TRAK-AT and 1050 Turbo have successfully been used in normal mode.

 

End of snippet.

 

So I'll never use my 1050 Turbo for copy issues but a 1050 Speedy instead.

 

If I'm riding the wrong horse here, just forget this post.

[lemiel]

AspeQT in US:

Computer sends '?' command, AspeQT reply with '06' for 68kbps.

Computer sets pokey to '06' and do transmission.

 

What I want in Turbo Mode:

Computer sends command (read, write, format, etc.) to AspeQT in standard speed. But the fourth byte of the block, carrying a byte value DAUX2 DCB block, is increased by 128 (ORA #$80).

After sending the command computer - without waiting for an answer from AspeQT - reprograms POKEY at 68.2 kbps (counter value (HS Index) - $06) assuming that that drive (emulated by AspeQT) also switches to the fast transmission.

Pick any negative answer of course is not possible in such system.

Further exchange of data caused by this one command is in an accelerated rate.

After transmission the command returns to standard speed.

Read and write schemas are described in ticket - http://sourceforge.net/p/aspeqt/tickets/6/.

 

So what I want to get AspeQT properly working with this scheme.

 

Hias AtariSIO works this way, so I think it is possible to have this option working in AspeQT.

 

 

There is nothing connected with speeder code on stack (page 1), because it can be on 6th page, or wherever code is assembled or relocated. So it should work with SpartaDos X - I used it this way that 15 years ago.

Edited August 31, 2013 by lemiel

[atari8warez]

@GoodByteXL

 

Walter, I've got your email about setting the time using AspeCL on SDX. I tried to reply to you and to Conrad on the subject but my mail was rejected by Conrad's mail server, so I decided to discuss the issue here. You said that AspeCL sets the time but still reports an error like this:

AspeQt CLient, (C) 2012 Ray Ataergin 
 
SpartaDos v4.xx detected
 
Polling server for Date/Time..
Date received from server..
Failed to set Time/Date! 

As we can see from above AspeCL receives the date/time from AspeQt and tries to set it (and indeed was able to set it in your case), but still reports an error by displaying "Failed to set Time/Date!"

 

AspeQt sets the Time/Date in two different ways depending the DOS system Atari uses; With SpartaDos AspeCL uses COMTAB vectors, with SDX it uses Kernel Vectors (page seven). Since you are using SDX, AspeCL used kernel vectors in your case. it stores received Time and Date values to $77E (time) and $77B (date) respectively, then stores $10 into $761 (device), sets kd_settd (set time and date) to $65 by loading Y register with that value, and does a jsr to $703 (kernel entry point) to set the Time and Date. On return from the kernel AspeCL checks for 0 (zero) in the accumulator for an indication of "success", otherwise it displays a failure message. In this case apparently the returned status code is not 0, thus the error message by AspeCL.

 

SDX manual is not clear about the return status codes for Time/Date functions. In fact the only mention of such codes is for block_io vector routines. I just assumed similar status codes are also issued for Time/Date functions. I may be wrong about my assumption. I am also kind of puzzled with the status return codes for block_io where 1 or 0 indicate success and a negative number indicates failure. I don't know why they chose to do it this way. Why both zero and one indicate success, wasn't it enough to use 1 for success and 0 for failure?. I guess only Conrad can answer these questions.

 

Here's the code snippet which sets Time/Date with SDX

aSDX1 						;SDX
			ldx #0
aLoo4
			lda aBuf,x
			sta sdate,x
			inx
			cpx #6
			bne aLoo4
						
			ldy #$65
			lda #$10
			sta sdevic
			jsr skernel
			
			cmp #0
			beq aOK

Edited September 5, 2013 by atari8warez

[flashjazzcat]

It's general practice to simply branch to error handling code when the negative flag is set on returning from the call, so I'd venture that the following might suffice:

jsr skernel
bpl ok

[error handling code here]

Obviously your code will fail if the function returns 1, which - according to the SDX docs - also signifies success. I don't pretend to have written code which calls kd_settd, but my interpretation of the docs is that you should simply react to the negative flag, just as you would following a call to - say - the CIOV.

 

Often I've written code which returns an error status in the negative flag, but might also wish to return extra information via positive values which the calling code may optionally react to.

 

In any case, if the code is setting the date but still thinking an error occured, then it's probably reasonable to conclude that the kernal call may return $01 on success.

 

You could also save a couple of bytes in your loop, incidentally:

			ldx #5
aLoo4
			lda aBuf,x
			sta sdate,x
			dex
			bpl eLoo4

Edited September 6, 2013 by flashjazzcat

[atari8warez]

Yes I realize my code needs change and I already know how to do it after reading the manual, my questions were however about whether the same status codes are also returned for date/time functions, as the manual is not clear about that and also whether there is any value in distinguishing between a status code 0 (success) and status code 1 (which is also success). Maybe instead of checking for negative (as suggested above) checking for separate success status codes would give me more insight on how the operation was successful!!...

Like, 0 = somewhat successful, 1 = Totally successful

Edited September 6, 2013 by atari8warez

[flashjazzcat]

See my edits.

[atari8warez]

See my edits.

Thanks, my objective here is not really to save a few bytes (and i am already aware of the availability of different 6502 op codes) but rather get an answer for status codes from the man himself or from somebody who was involved in developing the SDX kernel.

Edited September 6, 2013 by atari8warez

[drac030]

I am also kind of puzzled with the status return codes for block_io where 1 or 0 indicate success and a negative number indicates failure. I don't know why they chose to do it this way. Why both zero and one indicate success, wasn't it enough to use 1 for success and 0 for failure?

It is not so that "both zero and one indicate success", it is rather so that either 0 or 1 indicate success, a negative number indicates failure, and the rest of status codes are "user-defined". There are some analogies, e.g. Atari OS and DOS follow similar practice: here a negative number indicates failure, a 1 or 3 indicates success, and the rest is reserved for user definition. Therefore, for compatibility reasons, also SpartaDOS X sometimes returns 3 for success.

 

The basic rule is, as said above, to test for a negative value returned. So, instead of:

 

cmp #$00
beq OK

it is a better (safer) practice to do this:

 

cmp #$00   ;or TAY
bpl OK

It is easy to say why there is no simply "1 for success and 0 for failure": you're calling the kernel, and the kernel handles everything, including the FMS. Therefore it obviously must return a wider range of statuses than just success or failure.

 

It is not equally easy to say why either 0 or 1 indicate success, it is the original author who should be asked this. But I can guess, that, since the kernel is only a procedure which dispatches calls to different drivers and returns the results returned by these, some freedom was left to the authors of drivers, what to return as an indication for success: drivers are resident, and sometimes it may be convenient to save a byte or two by returning 0 instead of 1.

 

Now the fun part is that on my system the settd call returns 0 for success. The driver installed is the one for IDE+ clock. If on Walter's machine the returned value is different, then it might be either that:

 

1) it returns 1, as a valid alternative for a 0 indicating success, or

 

2) it returns something else, which means a bug in the driver.

 

Ray, could you prepare a test code for Walter, which code would display the value returned? If it is not 0 nor 1, I will also need an information which one of several clock drivers was in use.

[atari8warez]

Now the fun part is that on my system the settd call returns 0 for success. The driver installed is the one for IDE+ clock. If on Walter's machine the returned value is different, then it might be either that:

 

1) it returns 1, as a valid alternative for a 0 indicating success, or

 

2) it returns something else, which means a bug in the driver.

 

Ray, could you prepare a test code for Walter, which code would display the value returned? If it is not 0 nor 1, I will also need an information which one of several clock drivers was in use.

 

 

Conrad I tested AspeCL with several clock drivers and here are the results:

 

- With ULTIME (using SDX in U1MB) returned status code is 0 (zero) and the clock is set properly, Time/Date is set message displayed by AspeCL

- With IDEPTIME (using SDX in IDE Plus 2) returned status code is 0 (zero) and the clock is set properly, Time/Date is set message displayed by AspeCL

- With JIFFY returned status code is 0 (zero) and the clock is set properly, Time/Date is set message displayed by AspeCL

- With ARCLOCK /F (no clock hardware is present), returned status code is 4 (four) and the clock is not set, Failed to set Time/Date message correctly displayed by AspeCL

 

So my tests were as I expected, except for the status code returned by ARCLOCK was not a negative number, therefore a BPL did not work for displaying the correct error message but BEQ #$00 did.

 

I don't know exactly which clock driver Walter is using but I couldn't duplicate his problem here (actually setting the clock but displaying an incorrect message)

I am attaching a version of AspeCL which displays the Status Code returned by SDX before displaying Success/Failure message.

 

aspecl.zip

Edited September 7, 2013 by atari8warez

[GoodByteXL]

...

- With ARCLOCK /F (no clock hardware is present), returned status code is 4 (four) and the clock is not set, Failed to set Time/Date message correctly displayed by AspeCL

...

I don't know exactly which clock driver Walter is using but I couldn't duplicate his problem here (actually setting the clock but displaying an incorrect message)

I am attaching a version of AspeCL which displays the Status Code returned by SDX before displaying Success/Failure message.

The problem arose when using the ARCLOCK (chip RTC-72421). The crazy thing is, that time & date will be set correctly, but ASPECL-X reports:

 

AspeQt CLient, © 2012 Ray Ataergin

 

SpartaDos v4.xx detected

 

Polling server for Date/Time..

Date received from server..

SDX returned Status Code:4

Failed to set Time/Date!

 

Unfortunately, I cannot attach pics here. This forum just allows text writing, all other options are shaded and not available. I guess it does not comply with the security rules here ...

 

But I put photos up here:

http://home.arcor.de/walter.lojek/SDX/aspeclx1.jpg

http://home.arcor.de/walter.lojek/SDX/aspeclx2.jpg

 

At first the arc got set manually to 00:00 and 1-1-1 and then set correclty calling aspeclx. Sorry for the pic quality, it's a very sunny day today .

[flashjazzcat]

Nothing crazy about it. The program thinks non-zero is an error, so the driver sets the time but the app thinks something went wrong. Branching on the negative flag will solve the issue.

[atari8warez]

Well, There is gotta be a standard on returning the status code and status codes needs to be explained. A driver can't just return any value it wants. All other drivers return 0 when successful, the problem is with the driver returning an arbitrary status code. What does code 4 mean, the driver might have returned any value, a negative value too, and who knows whether it actually returns any value (4 might just be a residual number) so I don't think checking on negative flag is the proper solution.

 

Besides ARCLOCK returns 4 even when AspeCL can not set the date/time, because no actual hardware exists.

Edited September 7, 2013 by atari8warez

[flashjazzcat]

Why worry about it? A driver can return any value it likes for reasons I explained earlier, but I'll bet it'll never return a negative value unless there's an error. If we agree on the basic, simple idea that a negative return code means an error occurred, then all will be well. What are the standards on OS CIO return codes, for example? Do they always return 0 or 1 when no error has occured? Does anyone even know? Usually it's positive value means no error, negative means error. For the purposes of getting your program to work with all the drivers, I just don't see what the issue is with the non-error status codes. Just check for the negative flag and be done with it.

 

 

Besides ARCLOCK returns 4 even when AspeCL can not set the date/time, because no actual hardware exists.

 

But isn't that correct, since you supplied the "/F" switch to tell the driver there was no hardware to detect? Surely that's supposed to suppress a "no hardware present" error... which is what happened? Unless I'm missing something. If you leave the "/F" switch off, does it return a negative value?

Edited September 7, 2013 by flashjazzcat

[atari8warez]

But isn't that correct, since you supplied the "/F" switch to tell the driver there was no hardware to detect? Surely that's supposed to suppress a "no hardware present" error... which is what happened? Unless I'm missing something. If you leave the "/F" switch off, does it return a negative value?

 

I don't think so, firstly if there is no hardware and /F switch is not used the driver won't load in the first place. When /F is used the switch makes the driver load anyway. So the driver can be loaded whether the hw exists or not. When it comes to returning a status code however, the driver must distinguish between those two scenarios. If there is no hw present it should return a different status code then the one it returns when the hw exists and the clock can be set successfuly, otherwise how the caller can rely on any status code, whether it be positive or negative.

 

If i had to check for negative flag with the no hardware scenario, AspeCL would display "Time/Date Set successfuly" when it wasn't due to the driver always returning code: 4, regardless whether the hw exists or not. That in my books is not correct. The only solution for me then is to remove the "Success/Failure" messages altogether.

Edited September 7, 2013 by atari8warez

[drac030]

I don't think so, firstly if there is no hardware and /F switch is not used the driver won't load in the first place. When /F is used the switch makes the driver load anyway. So the driver can be loaded whether the hw exists or not. When it comes to returning a status code however, the driver must distinguish between those two scenarios. If there is no hw present it should return a different status code then the one it returns when the hw exists and the clock can be set successfuly, otherwise how the caller can rely on any status code, whether it be positive or negative.

No, that would defeat the purpose of the switch. It is only provided for a situation, when the clock hardware does exist, but the detection routine does not detect it for a reason. It was useful in development stage, then it was retained, because it was thought it might be useful for some testing. But that does not mean that the driver "has to distinguish between those two scenarios". Quite contrary, if the user forces the driver to skip the detection routine and load, the driver is supposed to act as if the hardware was present.

 

If i had to check for negative flag with the no hardware scenario, AspeCL would display "Time/Date Set successfuly" when it wasn't due to the driver always returning code: 4, regardless whether the hw exists or not.

Well, you should test for a positive/negative status, and not for a 0, because, as said above, the "success" code might officially be 0 or 1, and theoretically even 3. Of course, as I wrote above, "4" is most probably a bug in the driver. But as long as the state of the N flag returned is correct, that's a minor bug.

[flashjazzcat]

The only solution for me then is to remove the "Success/Failure" messages altogether.

 

I'm at a complete loss as to how this can be the conclusion, given the explanations provided. Let's break it down further:

 

N=1 : Error occured

N=0: No error occured

 

ARCLOCK.SYS /F: Suppress hardware detection (and thus error reporting).

 

Not the application's concern whether someone chose to start the driver up with the /F switch.