Memo Pad Pro!

[Laemeur]

Yeah, I know, the last thing in the world anybody needed was an updated version of Memo Pad, but this is sort-of a research project. I wanted to see proportionally-spaced text on the Atari, so took a shot at a simple implementation before beginning work on a more ambitious program. My real Atari is in a box 450 miles northwest of here, so I can only verify that this works okay in Atari800Win, both in OS-B and XL/XE modes.

 

I spent a couple nights just trying to get the character drawing as fast as possible, and I think I did pretty good, though I can still probably shave a few cycles off somewhere. No disk I/O, but it should print alright, which is almost as good with an emulator or an SIO2PC setup.

 

Anyway, screen shot is attached for your viewing pleasure, and here's a link to the .xex file: http://drop.io/memo_pad_pro_9bk

[candle]

looks nice

would you consider making cartridge version of it, so it could replace stock one? would be nice and refreshing for all of those 400/800 machines

[nathanallan]

looks nice

would you consider making cartridge version of it, so it could replace stock one? would be nice and refreshing for all of those 400/800 machines

I'd like to see this as well. Any homebrew is a good one! Yours looks nice. What are some of the 'extended' features going to be included in the more ambitious program? Cause that one is pretty impressive. I'd run it on real hardware for real.

[flashjazzcat]

I like this: it's really fast, too. Looking forward to seeing more features added to the program.

 

 

[candle]

one thing though

as i type, some keys presses are missed, and it seems that every keypress screen refresh is taking place - if its nessesary or not - this would greatly improove the speed it operates

[Laemeur]

I'd like to see this as well. Any homebrew is a good one! Yours looks nice. What are some of the 'extended' features going to be included in the more ambitious program? Cause that one is pretty impressive. I'd run it on real hardware for real.

I want to try and put together a sort-of simplified Swyft/Canon Cat type editor with navigation via "Leap"s, inline calculation, outline editing, and some other things. Proper cut/paste, disk I/O, and handling of large files are my immediate priorities, though.

 

 

I like this: it's really fast, too. Looking forward to seeing more features added to the program.

Thanks!

 

 

one thing though

as i type, some keys presses are missed, and it seems that every keypress screen refresh is taking place - if its nessesary or not - this would greatly improove the speed it operates

I have a few bugs in there, still! I'm not catching keystrokes properly apparently because there's some kind of timing issue when the edit buffer is too small and you're at the beginning of a line. Also, you'll start to lose keystrokes as you insert text in front of larger and larger buffers. And I have another bug in there where requests for a full redraw of the screen are piling-up when they're not supposed to. The good news is that all of these are fixable, and will be fixed. I just sorta bashed this out to see if I could.

[sloopy]

looks like a starting version of emacs... you have a atr or exe to try on my real atari?

 

 

sloopy.

[candle]

?! there is a xex file attached to the 1st post

[flashjazzcat]

I want to try and put together a sort-of simplified Swyft/Canon Cat type editor with navigation via "Leap"s, inline calculation, outline editing, and some other things. Proper cut/paste, disk I/O, and handling of large files are my immediate priorities, though.

 

I've been trying to figure out ways to create virtual memory pools using extended banks of RAM in order to edit extremely large files (32K, 48K, etc). There are lots of overheads, though, and it gets complex and slow very quickly when you're dealing in terms of a text editor. You'll be onto a winner if you can crack something like that. The other facilities sound advanced and ambitious, too.

 

I have a few bugs in there, still! I'm not catching keystrokes properly apparently because there's some kind of timing issue when the edit buffer is too small and you're at the beginning of a line. Also, you'll start to lose keystrokes as you insert text in front of larger and larger buffers. And I have another bug in there where requests for a full redraw of the screen are piling-up when they're not supposed to. The good news is that all of these are fixable, and will be fixed. I just sorta bashed this out to see if I could.

 

I would strongly advise the use of a non-linear text buffer, a la The Last Word. Arrange your text so the free space is always in front of the cursor. Text behind the cursor is moved to the low end of the buffer, pulled from the top of the buffer as you move through it and vice versa. Editing will be super-fast regardless of file size.

 

"Requests for a full redraw" is interesting. Do you have some kind of queueing system? I'm currently trying to work out how to implement a full-scale word processor using proportional fonts, so if you have any cycle-saving ideas to share, I'd be most appreciative!

Edited November 21, 2009 by flashjazzcat

[Laemeur]

looks like a starting version of emacs... you have a atr or exe to try on my real atari?

Here's an .atr version with the hiccuping keyboard and the too-frequent screen updates fixed: http://drop.io/MPP_ATR

 

I've been trying to figure out ways to create virtual memory pools using extended banks of RAM in order to edit extremely large files (32K, 48K, etc). There are lots of overheads, though, and it gets complex and slow very quickly when you're dealing in terms of a text editor. You'll be onto a winner if you can crack something like that.

That's way beyond my knowledge level right now

 

I would strongly advise the use of a non-linear text buffer, a la The Last Word. Arrange your text so the free space is always in front of the cursor. Text behind the cursor is moved to the low end of the buffer, pulled from the top of the buffer as you move through it and vice versa. Editing will be super-fast regardless of file size.

Yeah, that's absolutely on my to-do list for the actual editor, although I'm still trying to puzzle out how to actually implement it.

 

"Requests for a full redraw" is interesting. Do you have some kind of queueing system? I'm currently trying to work out how to implement a full-scale word processor using proportional fonts, so if you have any cycle-saving ideas to share, I'd be most appreciative!

It's nothing sophisticated at all. Right now the line-drawing routine starts at the current line and draws to the bottom of the screen, but it checks a flag when it's first called to see if it should start from the top line because the screen's been 'broken'. There are a few circumstances where that flag is set, and early-on my highly convoluted program-flow had it getting cleared before it should have. My incredibly crufty solution at the time was to have it get incremented/decremented rather than set/cleared so that requests for redraw could queue up. I'm back to setting/clearing now that I've got things happening in more or less proper order.

 

For a while I was trying to work out clever ways of 'marking' areas of the screen that needed updating, to save character-drawing cycles, but I eventually got the character drawing fast enough so that drawing a whole screen wasn't such an abhorrent time-suck anymore. Still, I would like to work on clever ways of avoiding redraws when not necessary, but I don't have any really useful information to that effect right now.

[flashjazzcat]

Yeah, that's absolutely on my to-do list for the actual editor, although I'm still trying to puzzle out how to actually implement it.

Pretty easy, and quite elegant. Set up two pointers in page zero: I call them POS and LINK. POS is simply the "address" of the cursor position. LINK is the address of the text stored at the top of the buffer, beyond the empty space ahead of the cursor. When a file is first loaded, it's moved to the top of the buffer. POS points to the bottom of the buffer, while LINK points to the first character after the empty space. To cursor forward through the document, you say:

 

ldy #0
lda (link),y
sta (pos),y
inc link
bne *+4
inc link+1
inc pos
bne *+4
inc pos+1

 

Obviously you need bounds checking, etc. To insert a character at the cursor position, you say:

 

lda char
ldy #0
sta (link),y
sec
lda link
sbc #1
sta link
bcs *+4
dec link+1

 

The buffer is full when POS=LINK-1. The screen refresh obviously has to skip over the empty space, so I use the EOL character as a marker at POS as well as an end-of-text marker at the very top of the buffer. This saves having to check where we're at all the time, since there can only be at most twenty-odd EOLs on the screen at once. When the refresh routine finds a return character, it checks to see if it's the one at POS. If it is, it grabs the value in LINK and continues drawing the screen from there. If it's the end-of-text marker, it knows it's done. If it's neither of these, it must a normal EOL character, so a return is printed.

 

A problem arises when you cross the blank memory and then word-wrap back to a point before the gap. There are a few different ways around this, but it requires careful management.

 

It's nothing sophisticated at all. Right now the line-drawing routine starts at the current line and draws to the bottom of the screen, but it checks a flag when it's first called to see if it should start from the top line because the screen's been 'broken'. There are a few circumstances where that flag is set, and early-on my highly convoluted program-flow had it getting cleared before it should have. My incredibly crufty solution at the time was to have it get incremented/decremented rather than set/cleared so that requests for redraw could queue up. I'm back to setting/clearing now that I've got things happening in more or less proper order.

 

For a while I was trying to work out clever ways of 'marking' areas of the screen that needed updating, to save character-drawing cycles, but I eventually got the character drawing fast enough so that drawing a whole screen wasn't such an abhorrent time-suck anymore. Still, I would like to work on clever ways of avoiding redraws when not necessary, but I don't have any really useful information to that effect right now.

The character draw routine must be really fast. In The Last Word, I keep a map of all the characters on the screen and any that haven't changed don't get redrawn on the next refresh. On top of that, I keep a table of the start address in memory of each line on the screen, and for each address which hasn't altered on the next redraw, even comparisons with the screen map are skipped for that line. Only the current and "previous" lines are redrawn at all times.

 

What I'm trying to figure out now is how to make this work with proportional fonts. You could still keep a buffer of which characters are on a line, but obviously if a line full of "i" characters gets a "W" written at the start, the whole line will have to be redrawn because everything will shift along by a couple of pixels. I guess the starting address of lines technique will still work. I also wondered, if the option to have a wide scrolling horizontal screen is offered, how large the character buffers might get. On a 640 pixel wide page, you could have a good 320 instances of the letter i on a line. This means double byte pointers and large buffers. Then there's the possibility that characters on the screen are italic or bold.

 

Anyway, your system already seems very fast and efficient. Well done!

Edited November 22, 2009 by flashjazzcat

[sloopy]

looks interesting, i tried it on my 800XL (bone stock) seems to work pretty well, would make a nice text processor, (vi controls? :') the currently edited line flickers a little, but nothing that is too obtrusive, full screen redraw takes a touch over a second, but didnt lose any keys while typeing during the refresh... but does print new characters on the same last line until refresh can get a new line open down at the bottom... interesting how the b/s delete key doesnt delete the letters if you b/s too fast until you are done hitting it... overall seems like a good start...

 

 

sloopy.

[joeventura]

looks nice

would you consider making cartridge version of it, so it could replace stock one? would be nice and refreshing for all of those 400/800 machines

I'd like to see this as well. Any homebrew is a good one! Yours looks nice. What are some of the 'extended' features going to be included in the more ambitious program? Cause that one is pretty impressive. I'd run it on real hardware for real.

 

Wow am I confused, you want a cartridge version of Memopad (pro)?

 

memopad pro is probably not a good name for this project since its not a replacement for the firmware based memopad.

 

What it is, is the beginnings of an editor or a word processor.

 

Just my opinion.

[+Roydea6]

I have noticed that CONTROL+SHIFT+ letter doesn't jump to several of the Alphabets (i.e.) A, B, and C for sure posibly more.

 

Is there ever going to be a LOAD feature.

 

I have tried getting different COLORS, but have not cycled to anything better than the original..

 

 

 

[Laemeur]

Pretty easy, and quite elegant. Set up two pointers in page zero: I call them POS and LINK. POS is simply the "address" of the cursor position. LINK is the address of the text stored at the top of the buffer, beyond the empty space ahead of the cursor. When a file is first loaded, it's moved to the top of the buffer. POS points to the bottom of the buffer, while LINK points to the first character after the empty space.

Haha. I must have caught this through telepathic transmission, because at the same time you were writing this it dawned on me what you meant in your previous post. It is an elegant solution, and it is the one I'm going to use. Thanks for sharing.

 

Unfortunately, last night when I hadn't quite caught your meaning yet, I spent a few hours hacking away at an incredibly convoluted linked-page buffer system which I shall now quite happily abandon in favor of your much simpler approach.

 

The character draw routine must be really fast. In The Last Word, I keep a map of all the characters on the screen and any that haven't changed don't get redrawn on the next refresh. On top of that, I keep a table of the start address in memory of each line on the screen, and for each address which hasn't altered on the next redraw, even comparisons with the screen map are skipped for that line. Only the current and "previous" lines are redrawn at all times.

I keep finding little ways to make it faster. Last night I got it up to about 1250 characters/sec, which is a skosh faster than what a VT52 terminal can get over its serial line, so I think I'm doing okay

 

I'm also using a list of initial-character addresses for each line, but then I just mark entire lines for redraw rather than individual characters. There's a trick, though, to ensure immediacy of feedback for the user. This is my current priority-order after a buffer-altering keystroke:

1 | Characters are inserted/deleted from the buffer.

2 | If a printing character was keyed, it is drawn immediately to the screen at the caret's current position. Because of this, the user can type faster than the line-drawing routine and still see their letters appear on the screen instantly.

3 | Starting from the first character at the top-left corner of the screen, line-breaks and caret position are calculated for the whole display, and the list of initial characters is updated. This calculation stops when it reaches the last visible line, or, if the caret has left the screen, once the caret has been found.

4 | Key-click is sounded to let the user know that the important consequences of their action have been handled.

5 | Caret is redrawn

6 | Interruptable line/screen redraw subroutine is called.

 

2 & 3 are really the key, I think. Having an up-to-date location for where the next character goes allows you to operate, more or less, like a mechanical typewriter, and just bash out one character at a time. The line/screen redraw is only really used to clean-up the mess that the typewriter-style drawing creates.

[Laemeur]

memopad pro is probably not a good name for this project since its not a replacement for the firmware based memopad.

 

What it is, is the beginnings of an editor or a word processor.

 

Just my opinion.

It's sort-of a joke. As it is, the program's just a proportional font demo with no load/save functions, and bad buffer handling. It's just barely more useful than Memo Pad, though, so I figured I'd be a smartass and call it Memo Pad Pro. That won't be its name when it's actually useful.

 

I have noticed that CONTROL+SHIFT+ letter doesn't jump to several of the Alphabets (i.e.) A, B, and C for sure posibly more.

I've noticed that, too. Can somebody verify that on real hardware? I'm pulling the key data right off of POKEY, so it's not being altered by the OS key handler routine. I suspect this is an emulation or PC problem, but if it's not, hopefully I can come up with a way around it.

 

Is there ever going to be a LOAD feature.

Not in Memo Pad Pro. In what I'm turning it into, yes.

 

I have tried getting different COLORS, but have not cycled to anything better than the original..

.

Blame your Atari. It's just cycling through the 16 hues in the hardware.

[sloopy]

memopad pro is probably not a good name for this project since its not a replacement for the firmware based memopad.

 

What it is, is the beginnings of an editor or a word processor.

 

Just my opinion.

It's sort-of a joke. As it is, the program's just a proportional font demo with no load/save functions, and bad buffer handling. It's just barely more useful than Memo Pad, though, so I figured I'd be a smartass and call it Memo Pad Pro. That won't be its name when it's actually useful.

 

I have noticed that CONTROL+SHIFT+ letter doesn't jump to several of the Alphabets (i.e.) A, B, and C for sure posibly more.

I've noticed that, too. Can somebody verify that on real hardware? I'm pulling the key data right off of POKEY, so it's not being altered by the OS key handler routine. I suspect this is an emulation or PC problem, but if it's not, hopefully I can come up with a way around it.

 

on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...

also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...

 

sloopy.

[Laemeur]

on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...

Darn! Thanks for checking that out, I really appreciate it. Now I know it's something I have to address.

also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...

 

sloopy.

Yeah, I knew about that. That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.

[sloopy]

on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...

Darn! Thanks for checking that out, I really appreciate it. Now I know it's something I have to address.

also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...

 

sloopy.

Yeah, I knew about that. That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.

 

 

np, if you want to find me in real time, i am usually on irc (irc.newnet.net channel #atari) when i am near my computer, and i am there when i am not near my computer, but i dont respond...

 

sloopy.

[Rybags]

SHIFT-CTRL doesn't work with a lot of keys... it's a hardware limitation on real machines.

[+Roydea6]

on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...

Darn! Thanks for checking that out, I really appreciate it. Now I know it's something I have to address.

also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...

 

sloopy.

Yeah, I knew about that. That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.

Original download not available anymore. Laemeur are we going to see anymore of this Pro....gram revisited.

[BillC]

on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...

Darn! Thanks for checking that out, I really appreciate it. Now I know it's something I have to address.

also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...

 

sloopy.

Yeah, I knew about that. That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.

Original download not available anymore. Laemeur are we going to see anymore of this Pro....gram revisited.

I don't know if asking will get any result, he hasn't accessed the forum since last November.

[+Roydea6]

Yeah, I know, the last thing in the world anybody needed was an updated version of Memo Pad, but this is sort-of a research project. I wanted to see proportionally-spaced text on the Atari, so took a shot at a simple implementation before beginning work on a more ambitious program. My real Atari is in a box 450 miles northwest of here, so I can only verify that this works okay in Atari800Win, both in OS-B and XL/XE modes.

 

I spent a couple nights just trying to get the character drawing as fast as possible, and I think I did pretty good, though I can still probably shave a few cycles off somewhere. No disk I/O, but it should print alright, which is almost as good with an emulator or an SIO2PC setup.

 

Anyway, screen shot is attached for your viewing pleasure,[DELETED OLD DOWNLOAD]

 

 

I asked 'Laemeur' if he would mind this atr being added to this thread, and he said that he didn't mind. So I'm adding it.

 

mpp.atr

 

Thanks Laemeur,

[+Stephen]

Thanks to both