Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4139 > unrolled thread

ProRWTS usage

Back to article view | Back to comp.sys.apple2.programmer

Contents

  ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-25 14:51 -0800
    Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-25 23:05 -0800
      Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-26 08:28 -0800
        Re: ProRWTS usage gids.rs@sasktel.net - 2018-01-26 09:54 -0800
          Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-26 10:51 -0800
            Re: ProRWTS usage gids.rs@sasktel.net - 2018-01-26 12:07 -0800
              Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-28 15:52 -0800
                Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-30 08:00 -0800
                  Re: ProRWTS usage gids.rs@sasktel.net - 2018-01-30 19:19 -0800
        Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-26 17:43 -0800
          Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-28 08:48 -0800
            Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-28 15:49 -0800
    Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-30 08:05 -0800
      Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-30 08:11 -0800
        Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-30 15:04 -0800
          Re: ProRWTS usage gids.rs@sasktel.net - 2018-01-30 17:05 -0800
            Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-30 17:10 -0800
              Re: ProRWTS usage gids.rs@sasktel.net - 2018-01-30 18:06 -0800
                Re: ProRWTS usage "Frank M." <frank_o_rama@hotmail.com> - 2018-01-30 18:48 -0800
                  Re: ProRWTS usage qkumba <peter.ferrie@gmail.com> - 2018-01-30 19:08 -0800

#4139 — ProRWTS usage

Hello all,

I'm writing a program which would benefit from faster loads from ProDOS into the AUX memory $800 (page 2) space. I can't use the ProDOS MLI as it does not load into $800. Was wondering a couple things about Peter Ferrie's ProRWTS to see if it would work.

https://github.com/peterferrie/prorwts

1- Will ProRWTS directly load into the AUX mem $800 space? (seems like the answer might be yes based on the fact that it can relocate to AUX to complete a transfer). I would like to avoid having to load data into memory using ProDOS MLI, and AUXMOVE into place. I only need to read data.

2- What assembler is needed to compile the code? I'm using Merlin8, mostly because I'm on rural broadband and don't want to download 4.5 gigs of xcode to compile a 1k program. Merlin32 doesn't want to compile it either. maybe cc65 with macports? I don't want to spend too much time on it if #1 is not possible.

Thanks for any advice!

Frank

[toc] | [next] | [standalone]

#4140

1) Yes, if ProRWTS is running from either LC or aux memory, then it can load files directly into aux memory.

2) ACME (https://sourceforge.net/projects/acme-crossass/).

[toc] | [prev] | [next] | [standalone]

#4141

Thanks for the reply. Unfortunately I don't think this will work for me for 'video' playback as my video files are loaded using an offset. To use ProRWTS it looks like I would need to break the video back into individual frame files (actually, two per frame; one for main bank, one for aux) and load based on a filename. (I've updated my frame rendering process for double-lores.)


The conundrum(s):

1- Can't load into $800 using prodos MLI so flipping page 1/2 isn't possible and playback displays some vertical 'combing' because the load is visible. Only showing page 1 at least runs pretty fast, but on heavy motion video it's noticeable. Using Vertical Blank mitigates this somewhat at the expense of speed, but full frame loads don't seem to be happening within the VBLANK period.

2- Could load into another area and use AUXMOVE but then playback will be slower on page 2 loading only. could add an artificial delay on the page 1 load to compensate, but don't want to slow down from the roughly 25-30 frames per second I'm getting with PD MLI and not page flipping.

ugh


Side Note--Peter, I ripped some 1-bit audio code from a previous post you had and integrated it for GR video playback with audio. Pretty cool proof of concept but would need to really refine a lot of things for a 'real release'. My next step is reworking your code into an audio recorder (plays back slow from the Compute! magazine recorder version because of the page balancing).

Frank

[toc] | [prev] | [next] | [standalone]

#4142

On Friday, January 26, 2018 at 10:28:45 AM UTC-6, Frank M. wrote:
> Thanks for the reply. Unfortunately I don't think this will work for me for 'video' playback as my video files are loaded using an offset. To use ProRWTS it looks like I would need to break the video back into individual frame files (actually, two per frame; one for main bank, one for aux) and load based on a filename. (I've updated my frame rendering process for double-lores.)


That is fine.  You would then need a copy of your video playback in Aux memory as well as in Main memory at the exact same address.  You can write a short routine to alternately toggle the Aux RAMREAD switch and the Main RAMREAD switch depending on where the frame is loaded.  This will take up very few cycles during play but takes up a bit more overhead to set up.

[toc] | [prev] | [next] | [standalone]

#4143

Rob are you saying that if I use AUXMOVE to make a duplicate copy of my app in AUX memory, I can use the ProDOS MLI to load into aux $800, but only if I call the MLI from AUX? then I do the main memory load once I've switch back into main memory?

Would you also have to move ProDOS into aux for this to work?

F

[toc] | [prev] | [next] | [standalone]

#4144

On Friday, January 26, 2018 at 12:51:58 PM UTC-6, Frank M. wrote:
> Rob are you saying that if I use AUXMOVE to make a duplicate copy of my app in AUX memory, I can use the ProDOS MLI to load into aux $800, but only if I call the MLI from AUX? then I do the main memory load once I've switch back into main memory?
> 
> Would you also have to move ProDOS into aux for this to work?
> 
> F


Correct.

You wouldn't have to move Prodos into Aux memory because the language card is separate from the main 48k area, but you will have to make a duplicate of the Prodos Global page ($BF00) in Aux memory.

It shouldn't matter which bank of memory is being used when the file is first opened, as long as the same bank is in effect when being closed.

[toc] | [prev] | [next] | [standalone]

#4149

> It shouldn't matter which bank of memory is being used when the file is first opened, as long as the same bank is in effect when being closed.

I don't think that this will work because then the file will become "desynchronised" with respect to the file offset because each bank will have a different value in the file buffer.

[toc] | [prev] | [next] | [standalone]

#4150

Can confirm that copying global page and app to AUX doesn't work. I can actually load correctly into page 1 aux, but not page 2 aux. Page flipping doesn't seem to be happening, either.

I got acme to compile PRORWTS2 last night, but haven't yet hooked it into my playback program to test. Wish I had written down the command line switches as it took a little fiddling.

Frank



On Sunday, January 28, 2018 at 3:52:04 PM UTC-8, qkumba wrote:
> > It shouldn't matter which bank of memory is being used when the file is first opened, as long as the same bank is in effect when being closed.
> 
> I don't think that this will work because then the file will become "desynchronised" with respect to the file offset because each bank will have a different value in the file buffer.

[toc] | [prev] | [next] | [standalone]

#4163

On Tuesday, January 30, 2018 at 10:00:03 AM UTC-6, Frank M. wrote:
> Can confirm that copying global page and app to AUX doesn't work. I can actually load correctly into page 1 aux, but not page 2 aux. Page flipping doesn't seem to be happening, either.
> 
> I got acme to compile PRORWTS2 last night, but haven't yet hooked it into my playback program to test. Wish I had written down the command line switches as it took a little fiddling.
> 


It is more than just copying the app, the global page and the file buffer to Aux.  Your program also has to make the right softswitch flips to read from Aux at the right time.

[toc] | [prev] | [next] | [standalone]

#4146

> Thanks for the reply. Unfortunately I don't think this will work for me for 'video' playback as my video files are loaded using an offset.

I have a ProRWTS v2 which does what you need.  It supports seek and read arbitrary amounts of a file.  The source is not commented well enough for release, but if you don't mind, you're welcome to try it.  Just e-mail me.

> Side Note--Peter, I ripped some 1-bit audio code from a previous post you had and integrated it for GR video playback with audio. Pretty cool proof of concept but would need to really refine a lot of things for a 'real release'. My next step is reworking your code into an audio recorder (plays back slow from the Compute! magazine recorder version because of the page balancing).

That sounds like a great project.

[toc] | [prev] | [next] | [standalone]

#4147

Sweet! Would like to check it out and beta test. I sent a message. Would be nice if you include a binary, but I can probably get acme to work (usually use Merlin8).

Frank


On Friday, January 26, 2018 at 5:43:43 PM UTC-8, qkumba wrote:
> > Thanks for the reply. Unfortunately I don't think this will work for me for 'video' playback as my video files are loaded using an offset.
> 
> I have a ProRWTS v2 which does what you need.  It supports seek and read arbitrary amounts of a file.  The source is not commented well enough for release, but if you don't mind, you're welcome to try it.  Just e-mail me.
> 
> > Side Note--Peter, I ripped some 1-bit audio code from a previous post you had and integrated it for GR video playback with audio. Pretty cool proof of concept but would need to really refine a lot of things for a 'real release'. My next step is reworking your code into an audio recorder (plays back slow from the Compute! magazine recorder version because of the page balancing).
> 
> That sounds like a great project.

[toc] | [prev] | [next] | [standalone]

#4148

I have replied to your mail.  Once you've checked the source a bit and let me know which options you require, then I can share a binary, too.

[toc] | [prev] | [next] | [standalone]

#4151

This is my latest working version. Page flip doesn't seem to work. Loading into Page 2 aux doesn't work. All of Page 1 load is fine. Page 2 aux is just showing white lines in the memory dump. Doesn't seem to do the page flip, either.

Feel free to let me know what doesn't make sense here, or can be removed (screenhole code?).

f



 ORG $1000 ; CALL 4096
SETUP CLC
 LDY #$07
SAVE LDA $0478,Y ; Save Scratchpad I/O Memory
 STA $330,Y
 LDA $4F8,Y
 STA $338,Y
 LDA $578,Y
 STA $340,Y
 LDA $5F8,Y
 STA $348,Y
 LDA $678,Y
 STA $350,Y
 LDA $6F8,Y
 STA $358,Y
 LDA $778,Y
 STA $360,Y
 LDA $7F8,Y
 STA $368,Y
 DEY
 BPL SAVE
 STA $C010 ; Clear keyboard strobe
 STA $C00D ; Set 80-col softswitch
 STA $C050 ; Turn on Graphics Mode
 STA $C052 ; Turn on Full Screen Mode
 STA $C056 ; Turn on Lores Graphics Mode
 STA $C05E ; Turn on Double-Lores Mode
 LDA #$C0
 STA $BF58 ; De-protect $400..$7FF in ProDOS memory map
 STA $C001 ; Allows $C054.C055 to change MAIN and AUX memory
 JSR $BF00 ; OPEN file
 HEX C8
 DW OPENPARM
 BNE ERROR
 LDA OPENPARM+5 ; Get file reference #
 STA READPARM+1 ; Store it with READ info
PLAY LDX $FF ; Playback speed parameter (POKE 255,X)
]LRP BIT $C019 ; Wait for next VBLANK period
 BPL ]LRP
]LP BIT $C019 ; VBLANK happening?
 BMI ]LP
 DEX
 BPL ]LRP
 SEC
 PHP
 SEI
 STA $C055 ; Set AUX memory
 JSR $BF00 ; READ 1/2 frame
 HEX CA
 DW READPARM
 STA $C054 ; Set MAIN memory
 BCS DISKERR
 PLP
 JSR $BF00 ; READ other 1/2 frame
 HEX CA
 DW READPARM
 BNE ERROR
 STA $C000 ; Switch $C054.C055 to change Page 1/2
SOFTSW EQU *+1
 STA $C055 ; Start showing Page 2
 LDA SOFTSW
 EOR #1 ; Alternate displaying $400/$800
 STA SOFTSW
 LDA READPARM+3
 EOR #$0C ; Alternate loading to $400/$800
 STA READPARM+3
 STA $C001 ; Switch $C054.C055 back to change MAIN/AUX
 BIT $C000 ; Check for keypress
 BPL PLAY
 STA $C010 ; Clear keyboard strobe
 BMI NOERR ; If keypress goto NOERR
DISKERR PLP
ERROR CMP #$4C ; Error an End Of File mark?
 BNE ERROR2
NOERR LDA #$00
ERROR2 PHA
EXIT JSR $BF00 ; CLOSE all files
 HEX CC
 DW CLOSEPARM
 LDA #$CF
 STA $BF58 ; Re-protect $400..$7FF in ProDOS memory map
 STA $C000 ; Turn off AUX memory mode
 STA $C054 ; Set Page 1
 LDA #$15
 JSR $FDED ; Turn off 80-col cleanly in ProDOS
 JSR $FB2F ; Set TEXT mode
 JSR $FC58 ; Clear screen (HOME)
 LDY #$07 ; Restore Scratchpad I/O Memory
RESTORE LDA $330,Y
 STA $478,Y
 LDA $338,Y
 STA $4F8,Y
 LDA $340,Y
 STA $578,Y
 LDA $348,Y
 STA $5F8,Y
 LDA $350,Y
 STA $678,Y
 LDA $358,Y
 STA $6F8,Y
 LDA $360,Y
 STA $778,Y
 LDA $368,Y
 STA $7F8,Y
 DEY
 BPL RESTORE
 PLA ; Pull ProDOS error code from stack
 BNE DOERR
 LDY $76 ; CURLIN+1, $FF if in direct mode
 INY
 BEQ DATA ; cleans SYNTAX ERROR when run from prompt
 RTS ; exit clean
DATA JSR $D995 ; update TXTPTR to next colon or EOL
 RTS ; needed to cleanup SYNTAX ERROR from CALL
DOERR JSR $FDDA ; Print error code byte
 BRK $00
OPENPARM DFB 3
 DW $0300 ; Filename Buffer
 DW $1200 ; Data Buffer
 HEX 00 ; File Reference #
READPARM DFB 4
 HEX 00 ; File Reference #
 DW $0800
 DW $0400
 DW $0000
CLOSEPARM DFB 1
 HEX 00 ; File Reference #0 Closes all open files

[toc] | [prev] | [next] | [standalone]

#4152

Meant to say:

page 1 main and aux load fine
page 2 main loads fine
page 2 aux only shows white vertical lines in emulator memory dump

everything seem to be loading in sequence properly

flipping pages between 1 and 2 is not happening. seems like it's stuck on page 1 which doesn't seem to be skipping any frames (if it was properly loading to page 2 it should only show every OTHER frame).

Frank

[toc] | [prev] | [next] | [standalone]

#4153

> page 1 main and aux load fine

The loads to $800 end up in main both times.
The sta to $c054 or $c055 doesn't work to load into page 2.
It does, however, work for page 1.  The reads to $400 work as expected.

That's why it's missing frames.
ProRWTS can help, since it keeps the file offset in the zpage.
However, there's a complication if you're running it from main memory, which is that at every 64kb boundary, you'd have to duplicate the 512 bytes tree buffer into aux memory so that it can be read when you switch banks.
If you're running entirely from LC, then there's no problem at all (other than ProDOS is gone, of course, so you can't exit).

[toc] | [prev] | [next] | [standalone]

#4156

On Tuesday, January 30, 2018 at 5:04:26 PM UTC-6, qkumba wrote:
> > page 1 main and aux load fine
> 
> The loads to $800 end up in main both times.
> The sta to $c054 or $c055 doesn't work to load into page 2.
> It does, however, work for page 1.  The reads to $400 work as expected.
> 
> That's why it's missing frames.
> ProRWTS can help, since it keeps the file offset in the zpage.
> However, there's a complication if you're running it from main memory, which is that at every 64kb boundary, you'd have to duplicate the 512 bytes tree buffer into aux memory so that it can be read when you switch banks.
> If you're running entirely from LC, then there's no problem at all (other than ProDOS is gone, of course, so you can't exit).



I haven't had the time to delve into Prodos yet, but what is keeping Prodos from writing to Aux using the $C005 instead of $C055 as in?

STA $C005
JSR $BF00
 HEX CA
 DW READPARM

Both the tree buffer and the global page are still available to Prodos in main memory.

[toc] | [prev] | [next] | [standalone]

#4157

The global page is written during calls (to preserve registers) but the changes won't be read back, and the internal file buffer won't be updated by the read.
That will cause the wrong register values to be returned (including what might appear to be an error code), and leaving the file position in its original place, causing the next read to fetch the same content.
i.e. bad things will happen.

[toc] | [prev] | [next] | [standalone]

#4160

On Tuesday, January 30, 2018 at 7:10:27 PM UTC-6, qkumba wrote:
> The global page is written during calls (to preserve registers) but the changes won't be read back, and the internal file buffer won't be updated by the read.
> That will cause the wrong register values to be returned (including what might appear to be an error code), and leaving the file position in its original place, causing the next read to fetch the same content.
> i.e. bad things will happen.


This is what I thought.  The file buffer and global page are getting written to Aux memory, but there is no way to read them back and so the information in main memory global page and file buffer are no longer valid.

[toc] | [prev] | [next] | [standalone]

#4161

Seems weird that it doesn't actually flip to page 2 at all though, though I understand why the frames are being loaded in their proper order.

Under ProDOS MLI, what if you call AUXMOVE to clone the data back to main memory after each page 2 load, then switch back to main mem?

I guess ProDOS MLI not actually being able to load directly into the $800 AUX area already makes it a moot point for my purposes. Weird it does work at $400 though.

With ProRWTS2, after calling INIT, clone it to aux at same location, open, read, exit? I don't need to close the file after reading it, correct? Does it always use main memory zero page for storing the file info? Will take me a couple days to update the code.

F


On Tuesday, January 30, 2018 at 6:06:03 PM UTC-8, gid...@sasktel.net wrote:
> 
> 
> This is what I thought.  The file buffer and global page are getting written to Aux memory, but there is no way to read them back and so the information in main memory global page and file buffer are no longer valid.

[toc] | [prev] | [next] | [standalone]

#4162

> Under ProDOS MLI, what if you call AUXMOVE to clone the data back to main memory after each page 2 load, then switch back to main mem?

You'd get the proper file buffer contents in that case, but the returned registers would still be wrong, for example (including spurious carry set and/or non-zero A register).  Not to mention the timing penalty for doing the copy.

> I guess ProDOS MLI not actually being able to load directly into the $800 AUX area already makes it a moot point for my purposes. Weird it does work at $400 though.

I suppose that's just how the hardware works.

> With ProRWTS2, after calling INIT, clone it to aux at same location, open, read, exit?

Yes.

> I don't need to close the file after reading it, correct?

Right.  There is no concept of "close" there.  You simply abandon the state.

> Does it always use main memory zero page for storing the file info?

Yes (technically, whichever one is active).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web