Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
Suggestion: "special" copying and pasting #65540 11/09/10 01:56 AM
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Hello, all.

Before contributing to the MESS MC-1000 emulation, I worked with another MC-1000 emulation implemented as a Java applet. To it I added some clipboard operations that have been proving very useful: 1) Copying/pasting a (plain text) BASIC program from/to the RAM (where it is tokenized). 2) Copying/pasting blocks of bytes from/to the RAM (or VRAM). 3) Copying/pasting the content of the text screen.

The ability to "inject" program and data directly from the clipboard, without resort to "tape" files, is very helpful while you are developing a new program.

What do you think?

Re: Suggestion: "special" copying and pasting [Re: Ensjo] #65541 11/09/10 02:15 AM
Joined: Aug 2009
Posts: 1,140
Kale Offline
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2009
Posts: 1,140
Isn't that already supported?

Re: Suggestion: "special" copying and pasting [Re: Kale] #65542 11/09/10 05:32 AM
Joined: Aug 2004
Posts: 1,385
Robbbert Offline
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,385
You can already paste as if you were typing it in. However it only works properly on some computers. Others produce gibberish.

Re: Suggestion: "special" copying and pasting [Re: Robbbert] #65543 11/09/10 05:36 AM
Joined: Jan 2006
Posts: 3,687
etabeta78 Offline
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Tafoid filed a bugzilla entry for the copy/paste problem with some systems (I think it depends on the delay some machines expect between sequential inputs)

concerning the original post, I think that he talks about something different. However:
1. copying and pasting RAM content requires some sort of snapshot format to be created, and however I think you can already use the debugger for that
2. BASIC tokens manipulation can be added to imgtool (I think coco supports this already if you need an example)
3. copying the screen content is something that I have no idea how could be implemented across the various different systems: one should probably intercept all the accesses to the RAM/VRAM and select the specific ones (it also reminds me too much the old hack used for c64 floppies, so that thinking to it already gives me nightmares... wink )

Re: Suggestion: "special" copying and pasting [Re: Robbbert] #65570 11/09/10 06:35 PM
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted By robbbert
You can already paste as if you were typing it in. However it only works properly on some computers. Others produce gibberish.

I know the pasting functionality that MESS has. It wasn't working well for MC-1000, then I recoded the keyboard input code and fixed it. Now it works almost properly, but the frequency of the pseudo-keystrokes is a bit too fast for pasting a long BASIC program, or one that has long lines, for instance. The time needed to process the input after every ENTER (tokenize the line and add it to the end of the program in RAM) causes the loss of the next keystroke (the first digit of the line number of the next line). I don't know if the frequency of these pseudo-keystrokes is adjustable in MESS.

Anyway, a long program still takes a lot of seconds to be inserted by this "pseudo-typed" pasting. The "injection" of data is immediate, and much more convenient. You can prepare a program in a text editor and paste it to the emulator every now and then for quick tests.

Originally Posted By etabeta78
concerning the original post, I think that he talks about something different.

Yes. smile

Originally Posted By etabeta78
However:
1. copying and pasting RAM content requires some sort of snapshot format to be created,

For BASIC programs, the format would be the program in text form. (Some escaping method could be considered to represent non-ASCII characters that many machines have.)

For generic RAM data, the format would be the same as in the Debugger's Memory Window: each line starts with an address, followed by a series of bytes to be inserted from that point on. (All hexadecimal, of course.) Example:
Code:
3000 00 00 00 00 00 00 00 00 10 10 10 10 10 00 10 00
3010 28 28 28 00 00 00 00 00 28 28 7c 28 7c 28 28 00
3020 10 3c 50 38 14 78 10 00 60 64 08 10 20 4c 0c 00
3030 20 50 50 20 54 48 34 00

Some tagging convention could identify specific pieces/banks of RAM:
Code:
[bank 1]
0000 00 00 00 00 00 00 00 00 10 10 10 10 10 00 10 00

[bank 2]
0000 00 40 40 48 43 20 30 33 34 4f 3b 20 20 20 20 20

Originally Posted By etabeta78
and however I think you can already use the debugger for that

Eh? I looked and found no copying or pasting feature in the debugger. Only direct typing.

Originally Posted By etabeta78
2. BASIC tokens manipulation can be added to imgtool (I think coco supports this already if you need an example)

Ugh, that stills involves creating a file (disk image?) in your system and loading it into the computer. And the machine emulated must have its disk capabilities implemented in MESS, which not all do.

Originally Posted By etabeta78
3. copying the screen content is something that I have no idea how could be implemented across the various different systems: one should probably intercept all the accesses to the RAM/VRAM and select the specific ones (it also reminds me too much the old hack used for c64 floppies, so that thinking to it already gives me nightmares... wink )

As it is the case with (de)tokenizing BASIC programs to/from the clipboard, that feature would need to be programmed independenty for each machine, with direct access to the (V)RAM.

Different machines have different BASIC dialects, with different tokens, stored in different formats at different points of memory. Internal pointers must be properly so that the machine knows the size of the program area.

As for the text screen, different machines have different screen sizes, different character sets, and so on... Some don't even have a "text" screen at all. In ZX Spectrum, for instance, characters shapes are stamped on a graphical screen, and the machine doesn't differentiate them from any line or dot plotted. It would be needed to compare every 8-byte-high screen square with the shapes in ROM to recognize the "text" content of the screen. For other machines, as those based on MC6847 like MC-1000 and the CoCo, it would be very trivial.

Re: Suggestion: "special" copying and pasting [Re: Ensjo] #65626 11/13/10 02:54 PM
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
It seems that my suggestion didn't rise much interest, at least here in the forums. frown

1. Is there a (more) proper channel to submit suggestions of change to the MESS core?

2. Is there any resource offered by the current core by which I could have read/write access the clipboard or a UI text box?

Re: Suggestion: "special" copying and pasting [Re: Ensjo] #65627 11/13/10 03:39 PM
Joined: Mar 2001
Posts: 16,390
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,390
I would suggest you instead fix the existing paste functionality to support a longer delay at the end of each line first.

Direct RAM save/load is best done in MESS as a "snapshot" - look at other drivers implementing snapshots for guidance.

Scraping RAM or VRAM is a terribly ugly kludge and I would push for rejection of patches implementing it on any system in MESS.

Re: Suggestion: "special" copying and pasting [Re: R. Belmont] #65632 11/13/10 05:03 PM
Joined: Aug 2009
Posts: 1,140
Kale Offline
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2009
Posts: 1,140
Or adding a "common" keyboard sub-routine for MCU-based keyboards on which we don't have a dump for.

Re: Suggestion: "special" copying and pasting [Re: Ensjo] #65633 11/13/10 05:17 PM
Joined: Jul 2007
Posts: 4,625
A
Anna Wu Offline
Very Senior Member
Offline
Very Senior Member
A
Joined: Jul 2007
Posts: 4,625
Quote:
It seems that my suggestion didn't rise much interest, at least here in the forums.


I am interested, especially for exotic computers with rare or nonexistent software.
The only way is then to type for your self a language listing to run.

Re: Suggestion: "special" copying and pasting [Re: R. Belmont] #65641 11/13/10 08:04 PM
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted By R. Belmont
I would suggest you instead fix the existing paste functionality to support a longer delay at the end of each line first.

I'm willing to do so, but... is it configurable on a per-driver base? How? (I'm still a newbie at programming for MESS, so more guidance is very welcome.) frown

Originally Posted By R. Belmont
Scraping RAM or VRAM is a terribly ugly kludge and I would push for rejection of patches implementing it on any system in MESS.

Forgive me, but why is that so? It's not obvious to me. As I said in the opening post, this feature is implemented in another MC-1000 emulator and it have been very, very useful. Editing a BASIC program in a text editor is much more comfortable that doing so in the machine, real or emulated, where I'm restricted to slow typing, one-line editing with slow cursor movement, no cut-and-paste, and so on.

(Don't take me bad. I am fond of the original machine, and programming in it is fun when you are in the mood to do so. But sometimes I just want to use a few minutes between my other occupations to try or improve a program for the machine to post on the wiki I set up for it, and doing that the usual way is just too time-comsuming.)

Even with a fully functional pasting feature, it is still "painful" to wait for long seconds (even minutes!) of beep-beep-beep-beep to get a full program in memory. And you don't have it the other way back: You can't (promptly) retrieve a program that you have typed in the machine after you edited it there.

Originally Posted By R. Belmont
Direct RAM save/load is best done in MESS as a "snapshot" - look at other drivers implementing snapshots for guidance.

Beyond the fact that a snapshot involves a file, it is originated in the machine. I get the status of the machine and save it so I can resume to that state later. People don't create snapshots outside of the machine. And (I suppose) it's generated in binary format, reflecting the RAM content, so the BASIC program is stored there in tokenized format, not text-only. Still, I can't (easily) use snapshots to insert an all-new program into the machine, and to retreive the source code of a BASIC program originally typed in the machine.

Given that, what is it that makes direct (V)RAM copying/pasting such an un-welcome feature?

Page 1 of 3 1 2 3

Who's Online Now
1 registered members (Pernod), 179 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,722
Posts114,633
Members4,873
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3