So, I am working on another fun project on my trusty old TRS-80's.
I need the ability to do multi-line functions which TRS-80 BASIC
does not support. But in hopes of finding something where someone
added that capability in the distant past (there were lots of features
added by various people over time) I decided to just try a Google
Search. As we all know Google now begins results with an AI generated
answer to your question. This is what I got:
--------------------------------------------------------------------------
In TRS-80 BASIC, you can create multi-line functions (subroutines)
using the DEF FN statement, allowing you to define a function that
can perform a specific task and be called from different parts of
your program.
Here's how it works:
DEF FN Statement:
You use the DEF FN statement to define a function, followed by the
function name (e.g., FNMyFunction), a set of parentheses for any
arguments, and then the code that the function will execute.
Example: 10 DEF FNC(X,Y) = X*X + Y*Y defines a function named FNC
that takes two arguments (X and Y) and returns the sum of their squares.
Function Call:
To use the function, you simply call it by its name, passing in the
necessary arguments.
Example: 20 PRINT FNC(3,4) would print the value returned by the FNC
function when called with arguments 3 and 4, which is 25.
Multi-line Functions:
You can extend the DEF FN statement to span multiple lines, allowing
for more complex logic within the function.
Example:
Code
10 DEF FNC(X,Y)
20 LET TEMP = X * X
30 LET TEMP = TEMP + Y * Y
40 DEF FN END
50 PRINT FNC(3,4)
This example defines a function that calculates the sum of squares
of two numbers, but the calculation is broken down into multiple
lines for readability.
Key Points:
Line Numbers:
TRS-80 BASIC relies on line numbers, so make sure to use them
appropriately when defining multi-line functions.
Function Name:
Function names must start with FN followed by a valid identifier
(e.g., FNC, FNMyFunction).
DEF FN END:
You need to use DEF FN END to mark the end of the function
definition, especially when using multi-line functions.
Scope:
Functions are defined within the scope of the program and are
accessible from anywhere in the program.
-----------------------------------------------------------------------
Which is both wrong and totally absurd.
And I see things all the time about letting AI write your code for you.
Does anyone actually trust AI to write code?
bill
I have a scan of the following:
LSI-11 BUS INTERFAE CHIPKIT/PROGRAM CONTROL DCK11-AA,-AC
October, 1977
Phil Champaigne
Logic Products
MR2-2/X6645
If someone is interested in a copy, preferably someone who can host
it, please contact me.
don
The why not use a UniBone comment has merit, what will your (FPGA)
> implementation add ?
>
Well,
I know the Unibone!
Surely is a very capable system for emulation of older hardware and
interfaces.
Also performances are good as far as I understand (I don't have one).
I have the idea of extending the concept of Unibone.
The new design shall be modular, composed by:
- a main board hosting the SoM and common interfaces (Ethernet, SD, USB,
console)
- a bus module for specific bus / machine: support could be added for DEC /
Data General / other?
- an interchangeable interface module for an hardware device (SMD, Pertec,
floppy, RX1/2, RL01/02, other).
Any kind of interface could be supported, also for example ADC, DAC, maybe
video to some limits...)
If you have main module and bus module, you have a similar solution to
Unibone / Qbone. However if you need to change bus type, you need to swap
only the bus adapter (cheaper).
If you have main and interfaces modules,
you can control physical devices directly,
and do anything with it. For example, you can dump / restore the content of
a SMD disk at bit level, no need to know the controller format, etc.
Similar to Kyroflux for floppy, but MUCH faster!
Alternatively, you could also emulate the device at low level (for example
a generic SMD disk).
If you have a set of main, bus and interface modules,
you can do anything as above, plus you can emulate a controller for a
specific machine for a specific device.
That said, implementing "anything" would be an infinite effort, but the
platform is flexible, so support could be added step-by-step.
So why an FPGA?
A programmable logic can implement a true digital circuit, where the PRUs
in the BeagleBone are processors. This means that in an FPGA the time is
always precisely determined by a clock, in PRUs it is affected by the
software execution.
This means that a PRU can work quite well on an asynchronous bus, provided
that sample rate is sufficient, even if not constant.
But for a fast synchronous interface, i.e. when time is determined by an
external clock, often embedded with data, no software approach can work
steadily in my opinion.
One thing is true: programming an FPGA is designing a netlist, not
developing a software.
It can be very hard to debug sometimes, because the approach is more
similar to repairing an old board with a Logic Analyzer than perform
debugging in software: it's a circuit in a chip, there no step-by-step
execution!
Nevertheless:
I'm a quite good electronic engineer,
highly experienced with digital logic and FPGA, so the hardware design
wouldn't be a problem. Just a matter of time.
Nowadays a SoM with a smaller AMD Zynq7010/7020 (a system-on-chip including
an FPGA, plus dual core CPU, lot of peripherals) doesn't cost a lot,
and have a great usage flexibility.
Also brute computing power is superior to older BB.
Why not try?
I'm open to your comments.
As for the UNIBUS unobtainable transceivers: I think the best solution is
to use AM26S10 for drivers, and an LVC logic powered at 3.3v for receivers.
Both are active parts costing nuts.
I would try this approach.
Andrea
