Development Tools Survey

[sark02]

GARTHWILSON wrote:

If it's something to run on the workbench computer itself, I just mark a block in the source code in the text editor on the PC and "print" the block on the RS-232 port as if to a serial line printer. The PC thinks it's just printing; but the workbench computer takes that text and compiles, assembles, or interprets on the fly, as appropriate.

That's actually quite brilliant.

[GARTHWILSON]

The workbench computer thinks you're entering the code on an RS-232 keyboard and that you type a bazillion words a minute without ever making a mistake. (Of course if there is something it doesn't understand in the source code that's coming in, it will tell you on the character LCD and the printer.)

If you later want to put it in ROM, you can run the metacompiler on it in the PC, after it has already been proven. Or, if assembly language, some syntax changes will be needed to assemble it with the PC, since the Forth assembler is a little different. Fortunately, since it's Forth, full macro capability is easy to get even though it's very simple and doesn't take much memory.

[Klaus2m5]

Quote:

For those of you who bypass emulation and go straight to target, how do you load the code onto the target?

The target is an emulator with RAM only and a monitor as part of the hosting microcontroller. The monitor loads to RAM from terminal or serial EEPROM.

[BigDumbDinosaur]

sark02 wrote:

Emulators: custom, Kowalski,none, VICE

Note that VICE, the Kowalski environment, etc., are simulation, not emulation. Emulation is usually the province of hardware, resulting in a behavior that is identical to or very close to that of the emulated hardware (I think we had a topic going on this a while back). Simulation is generally done in software, often on a machine that has no architectural similarity to what is being simulated.

Quote:

For those of you who bypass emulation(sic) and go straight to target, how do you load the code onto the target?

The procedure with my POC unit is as follows:

1. Edit and assemble the code in Kowalski.
2. Put POC into load mode via an M/L monitor command. The command to set up a load is L [<bank> [<page>]], where <bank> and <page> may be used to load into any bank and optionally with relocation to any page within that bank. The load function opens the auxiliary serial port and readies it for data inflow.
3. Save the object code generated by Kowalski in Motorola S-record format. This takes a little explaining.
   
   Normally, saving object code in S-record format would write a file. As my Windows file and print services run on Linux, not Windows, I have some flexibility at my disposal. In every subdirectory in which I do 65C816 development is a file called binary code.65m, which is a symbolic link to a static file named aout.65m. Windows, of course, doesn't know that binary code.65m isn't a real file, as Samba makes symbolic links look to Windows like regular files. When object code is written into one of the binary code.65m symbolic links the data ends up in aout.65m.
4. A daemon running on my Linux box looks at aout.65m at two second intervals and compares the file's current time-stamp to what it was the last time it looked at the file. As the time-stamp will change when the file is written, the daemon will see a newer time-stamp, read aout.65m and pipe its content to my UNIX box via the network.
5. The UNIX box also has a daemon that listens for a network connection on port 65534 (a dynamic port). When a connection is made, the daemon will direct the incoming data flow to a specific serial port on the Equinox serial hardware that is attached to my UNIX box. That port is wired to the auxiliary serial port on POC. An stty command sets up the communications parameters and data is ready to flow.
6. POC reads in the data flow an S-record at a time, converts each record to binary, checks it for errors and if satisfactory, pokes bytes into RAM. A dot is printed to the console for each record successfully processed.
7. When an S9 record has been received and processed the load has completed, the serial link is broken and the code is ready to be run. The final step is for the MPU's PB and PC shadow registers in the M/L monitor to be updated with the execution address of the program. Typing G or J will immediately execute the code.

Although this process sounds convoluted it is quite fast. The serial link to my UNIX box runs at 115.2 Kbps, so even a large program loads in only a few seconds.

[sark02]

BigDumbDinosaur wrote:

Note that VICE, the Kowalski environment, etc., are simulation, not emulation. Emulation is usually the province of hardware, resulting in a behavior that is identical to or very close to that of the emulated hardware (I think we had a topic going on this a while back). Simulation is generally done in software, often on a machine that has no architectural similarity to what is being simulated.

Ha! Not taking the bait. Now give me a second while I compile my assembly language file.

Quote:

The [download] procedure with my POC unit is as follows:

That's a fun little sequence. With your 2s file timestamp polling, do you ever see partially written files?

[BigDumbDinosaur]

sark02 wrote:

BigDumbDinosaur wrote:

The [download] procedure with my POC unit is as follows:

That's a fun little sequence. With your 2s file timestamp polling, do you ever see partially written files?

No. The reason is when the time-stamp is checked and discovered to have changed, another check is made one second later to see if the time-stamp has changed again. If it has, the process is restarted, as it is presumed that the file is still being written. Only after the time-stamp remains unchanged for at least two checks is the file read. That prevents a partial read scenario from developing.

[White Flame]

OS: Linux Mint. Windows has long expired in terms of privacy, basic configurability and "get out of my way"-ness.

Editor: No preference. I happen to use emacs because I'm a heavy Lisp user. As long as it auto-indents, I'm happy.

Assembler: ca65. I've tried a bunch of others over the years. ca65 is the most powerful, though I've not yet tried KickAssembler.

Emulator: VICE.

Tools wishlist: Nothing that I can't build myself comes to mind...

[floobydust]

Since I got back into the 65xx stuff a few years back, I bought the WDC Tools suite when they first reduced the price to under $50. I also bought UltraEdit so I'm using Windows 7 Pro 64-bit which is running under Fusion 8 Pro on a CustoMac running OSX Yosemite.

I have 3 65C02 based setups which are basically the same, sans one with a different serial interface. I use a dual FTDI USB to Serial adapter which gives me two RS-232 ports which allows me to connect two systems, the FTDI interface is assigned to the Win7 VM. The 3rd system has a FTDI DB9 USB to serial adapter which is also assigned to the Win7 VM. I use ExtraPutty as a console to connect to the 65C02 boards. I have 3 sessions open, one for each board.

As for loading code to the boards, I have a Dataman 40Pro programmer which is also attached via USB to the Win7 VM. Overall, it gives me a pretty simple and straightforward development setup which is portable in the fact that I can move the VM to my MacBook Pro and drag a board with me when I travel.

My other option for loading code is via ExtraPutty's Xmodem CRC support. The monitor code supports Xmodem CRC downloads via the console port itself and allows a load address to be specified before the transfer starts, or defaults to $0800. The monitor Xmodem loader also automagically detects S19 records created by the WDC Tools linker and directly places code into memory with an optional offset (in case of code assembled for ROM). Once the code is in RAM, I can either execute directly or burn to EEPROM insitu via the monitor which has a program EEPROM function as well.

Overall it's a pretty straightforward but very stable environment. I use one system for active development and the other two as long term code testing... usually running a stable build for months at a time.