Would anyone be interested in giving me a quote to convert (or pseudo code)
several R83 Assembler programs? I have the two main routines mostly
re-written but I'm curious if I have left out any major components or
features and I have a client in need of an update. I would like to be able
to give them as much reassurance as I can that the application will function
the same on D3 as it did on R83.

I know one of the routines is about 200-300 lines long and they appear to
have some documentation in the source. If anyone is interested, please send
me an email with your initial thoughts and requirements (time needed, cost,
etc).

Thanks in advance.

Curt Stewart
TRI-SYS Consulting
cstewart2 @ Earthlink.net

Not that I can DO the job, but could you confirm for those that may be
interested that the code in question is actually "owned" by your client
and that they will not fnd themselves embroiled in any nasty
copyright/piracy disputes ?!

Good to see you Curt! Long time...

I'm afraid I wouldn't be qualified to do the code, precious few people
are. There are some big changes involved:
- mode names have changed or have been split into other functions.
- setups/interfaces to existing modes changed.
- PCB, SCB, etc have all changed - bits shifted around, new storage
registers to setup, some tallies increased to doubles, etc.
- frame and item header format have changed.
- frame size changed if you're hardcoding frame boundaries.
- You can't write modes for D3NT, only *nix.
- Virtual code requires a re-assembly in almost every D3 release.

I will suggest that some code which people used to write in assembler
might best be re-written now in BASIC, which in D3 can even be used
for raw frame I/O. Now _this_ I can do. Some code doesn't even
belong in the Pick environment - it was only there because back in the
day there was no alternative. Consider shelling out to execute
functions and return data back to D3 which is operating more as a
database and application server than an operating system.

Outside of that advice, Mark Brown might be your only saviour.

HTH
Tony

---------
Spoon boy: Do not try and bend the spoon. That's impossible.
Instead... only try to realize the truth.
Neo: What truth?
Spoon boy: There is no spoon.
Neo: There is no spoon?
Spoon boy: Then you'll see, that it is not the spoon that bends, it is
only yourself.

Hi Curt,

I could could give it a try if you like, but I can't really give you
much idea of how long it will take until I see the code. It could be a
day, or if it's really nasty, it could be a week.

My rate is 100 Australian pesos (around US$72) per hour. Naturally, I
wouldn't charge for the time spent putting together a quote.

Regards,
Luke

Curt Stewart wrote:

Tony Gravagno wrote:
I'm pretty sure that when Curt mentioned converting the code, he would
have been talking about converting it to BASIC. Or possibly to C, but I
think BASIC would be best.

Probably not. There's me, Chandru, Frosty (John) and at least a couple
of other subscriber, plus I know at least one other here in Australia.
We might be a little rusty, but it's amazing how quickly it all rushes
back. (Oh, the flashbacks!)

Luke

That's a good point. Thanks for asking.

I own the code. My company wrote it 15 - 20 years ago, so we don't have to
worry about copyright issues.

Curt

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Hey Tony,

Sorry I didn't mention that I want to end up in Basic. When I said I had a couple of the programs, mostly re-written, I just forgot to mention that they are re-written in Basic. And, you are right, everything that these modes are doing can be done in Basic or at the OS now. It still impresses me though how much we were able to do on a 17 user, R83, 286 with 640mb memory.

There are 26 user modes/entry points that are defined. I don't know how this relates to actual programs and source code. Of the 26 there are 3 that I know I don't need for basic, there are the two main modes, with 4 or 5 entry points, that are probably 80% & 90% complete, and then there are 10 I'm pretty sure that have built-in equivalents now. The rest don't appear to be that critical but all I have to make my judgment on is a short title/description and the fact that the issues I've uncovered so far haven't led me back to those user modes.

So, I don't actually need the assembler programs converted into compileable code, Pseudo code, or at least a description of what it was doing would be enough. That way on the main modes I can confirm that I've covered all the bases and on the rest, if I need to re-write them, I at least know what they were doing in the first place.
I'm in the process of getting the source off of the r83 machine and into text files so that I can forward them to everyone that responded to my initial post.

In case you're wondering here is a list of the descriptions I have of what the user modes do.
Single character input (all keys & combinations, todays IN)
Input Mode, 3 entries Overwrite, Insert and Append
FCODE processor (Processes stacked and nested fcodes)
* these are the ones that are mostly done.
STON flag from Proc
List Present
TCL Sentence
Trim Leading
Trim Trailing
Strip Parity - Not sure about this one
Proc Flag
Printer Type for Basic
Return list to Basic as a Dynamic Array
Count items in list
Read Previous
Count Value Marks in string for Basic
Count Value Marks in string for F-Code
Initialize Workspace
Release Workspace
Reset Workspace
Display ID
Display Item
Display Window
Display Output Fields
Thanks for your responses, interest and help.

Curt

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Yeah, we all know about you "fly by night" lot :-)