A first look at SLOPe

[hydrophilic]

GEOS emulation... talk about feature creep! LOL

As I recall, the Paint format is quite straight forward, an array of bitmap 'blocks' each 80 columns / 640 pixels wide and 8 pixels tall in the VIC standard bitmap/char fashion.  The height (number of blocks) is variable and each block is pointed to (track/sector) in the VLIR sector (so I guess it's limited to 127 blocks).  Dunno about Write or Fonts.  I liked the GeoFont editor but that's another topic...

I dunno about the APIs either but most data is passed through zero page variables as I understand it.  You said earlier that SLOPe uses dynamic page 0 and 1 allocation.  Which brings me to my question.

How do you handle page 1 switching?  I always thought about using that feature, but since interrupts (especially NMI) can occur durring switching stack pages I never thought it would be reliable.  Thinking about it more now I have a few ideas, but was just curious what your solution is.

Also what about stack overflow?  Since there is no hardware support for detecting this it was another reason I nevered used page 1 switching.  My only ideas were to constantly check the SP which is just wasteful or perhaps check it during an IRQ.  The IRQ is more effecient but not reliable at all.

Anyway, have fun!

[xlar54]

Niko - Ive missed out on all the screenshots and videos, but would like to check this out - is there somewhere I can see what you have done so far?

[nikoniko]

Hi xlar, screenshots are fixed above, though now they're very out of date since I've been doing a complete rewrite of SLOPe from the bottom up. I didn't like that there wasn't better integration with the 128's usual mode of operation, so I started over from the view of making SLOPe a system extension rather than a complete replacement. After I get caught up on the two weeks of posts I've missed while sick, I'll write more about it and post some new media.

[nikoniko]

GEOS emulation... talk about feature creep! LOL

After studying the GEOS architecture with my book, I've now set that idea in the "probably never" pile. Initially I thought it might by feasible by redirecting the API calls to SLOPe routines, but there are just too many differences for that to work. However, I think something could maybe be worked out so that GEOS and SLOPe can coexist -- sending one into hibernation and running the other, then switching back.

Fonts, Paint and Write files will definitely be supported, though.

How do you handle page 1 switching?  I always thought about using that feature, but since interrupts (especially NMI) can occur durring switching stack pages I never thought it would be reliable.  Thinking about it more now I have a few ideas, but was just curious what your solution is.

Two ways. The first is deliberately triggering an NMI via CIA2 right before the swap, but not touching the interrupt control register until after swapping the page. The second method is if there's an REU attached, store all the page 1s in expansion RAM and swap them when needed. That's a nice solution because 1) the actual RAM location of page 1 can remain static and we don't need to mess with relocation, and 2) the processor is halted, so NMIs will leave us alone until we're done. But my redesign also reduces stack usage significantly, enough so that I think ultimately I'll be able to dispense with giving programs their own page 1 altogether. (EDIT: Actually, userland programs no longer use the hardware stack at all.)

Aside from those options or disabling NMI completely, what other ways can you think of to safely handle such switching?

Also what about stack overflow?  Since there is no hardware support for detecting this it was another reason I nevered used page 1 switching.  My only ideas were to constantly check the SP which is just wasteful or perhaps check it during an IRQ.  The IRQ is more effecient but not reliable at all.

Well, "sloppy" is the name, so I haven't been that worried about wasteful. But I think the changes I'm working on will reduce the possibility of stack overflow significantly, pretty much eliminating the need for constant checking, though once you see how it's done you might want to revoke my license to develop for the 65/85xx architecture...

Anyway, have fun!

I have been. Working on SLOPe with VICE on my laptop kept me from going stir-crazy the last couple of weeks.

[hydrophilic]

I like the REU idea to the NMI problem!  The CIA triggered NMI seems wasteful but the fact you bothered to code for that shows you're good 'nuf for 6502 coding

My recent idea for page 1 flipping (never tested mind you) is to have a 'dummy' page 1 and use it during swap.  Something like this...

Code Select Expand

LDY mmu_p1 ;old stack page
TSX
TXA
STA sp_table,Y ;save SP for old stack

LDA #dummy ;temp stack page
STA mmu_p1

LDY #new_p1 ;new stack page
LDX sp_table,Y ;SP for new stack stored in memory
TXS
;an inerrupt here would kill old_stack
;that's why have dummy stack
STY mmu_p1
;interrupts ok in new_stack
The idea is the entire 'dummy' page can be written by interrupts, should they occur, without the SP being set properly yet.  Once the SP for the 'new' stack is correct we can switch in the correct page.

That is, the 'dummy' page takes care of any interrupt between TXS and STY mmu_p1 opcodes.

The main problems I see with this method are you'd need to use self-modifying code (to set the LDY #nn) or a fixed address (LDY $zz or LDY $aaaa).  In other words I don't think it could be used recursively.

Ahhh.  How to explain?  The main code could set up multiple stacks in a recursive fashion but the problem I mention would be the interrupt routines couldn't use that same code to setup a dynamic stack page.

The interrupt code can easily setup a constant stack page for itself if no other interrupts are possible.  So I guess IRQs couldn't do it but NMIs could.  Assuming we don't trigger an artificial NMI just to avoid them.

Now that I've confused everyone (myself included), I'll shut up.

[airship]

The C128 MMU allows multiple page 0 locations, but I don't think anyone has used that feature much. I don't suppose that code could be stolen and reworked to allow multiple page 1 (stack) locations? Just a thought...

[Stephane Richard]

Just wondering three things ;-)>

1. Any new development to report?  a fixed bug, an addition to the todo list? ;-)>
2. What are the 2008 goals with it?
3. Early 2008 imeans what to get your site up and running? ;-).  ehe.. I can't wait to go play in your PDF background ;-).

[nikoniko]

1. Most significant is probably that CC65 has been taken out of the development process. I was having to spend more time rewriting CC65 to support SLOPe than I was getting to work on SLOPe itself, so using C wasn't really supporting my plan of making things easier. In some cases I'm still working with code that was previously compiled, but all new code is being written in assembly and eventually the legacy code will be redone from scratch. I suppose I should mention that the GUI system is no longer functional. However, now there's a working TUI where there hardly was one before, and VIC support.

2. Besides support for operating together with the 128's normal environment, continuing the overhaul of the memory management and task system to be simpler and faster. Most of that work is already completed, but further supporting those and several other goals (eg. memory protection, unburdening the hardware stack), user applications are changing to a p-code style system. As slow as that may sound, remember that most (if not all?) of the BASIC compilers for the 64/128 machines compile to p-code and end up with performance better than the BASIC interpreter. Simple tests I've done bear out the same for SLOPe, which frankly surprised me since I've done absolutely zero optimization on the p-code interpreter. Critical code like drivers can still run natively, but generally I think keeping as much as possible within the p-machine will be better overall. Currently the only means of generating the p-code is a very limited BASIC compiler. I think BASIC is a good way to go since it provides an easy upgrade path for many existing programs. Other important goals: reintroducing GUI support.

3. I enlisted the help of a friend to do the frontend since I stink at design. Visually it's something along the lines of Alibris, but with support for downloads, user tags, and online PDF viewing. It's no longer just a PDF library but a catalog of Commodore-related books and links to places where they can be bought.

[airship]

Wow! The PDF library is going to run at a full 2 Mhz?  

[nikoniko]

Yep, and not a Mhz more! 2Mhz ought to be enough for anybody, don't you think?