Apple-2-SW/contiki
1
0
Fork 0
mirror of https://github.com/oliverschmidt/contiki.git synced 2025-01-02 19:29:30 +00:00
Code Issues Projects Releases Wiki Activity
919124fd97
contiki/platform/apple2enh/Makefile.apple2enh

80 lines
3.1 KiB
Makefile
Raw Normal View History

Added make target 'disk' for creating a .dsk disk image using AppleCommander.
2008-05-22 22:21:43 +00:00
#
# Copyright (c) 2007, Adam Dunkels.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. The name of the author may not be used to endorse or promote
# products derived from this software without specific prior
# written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
# GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# This file is part of the Contiki operating system.
#
# Author: Oliver Schmidt <ol.sc@web.de>
#
Added SLIP support to retro platforms. The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet. Some notes: - The Ethernet configuration was simplified in order to allow share it with SLIP. - The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer. - As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent. On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically. On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
2017-02-15 22:43:28 +00:00
DEFINES += STATIC_MOUSE=a2e_stdmou_mou
ifdef SLIP
DEFINES += STATIC_DRIVER=a2e_ssc_ser
endif
Updated several aspects regarding Ethernet drivers. I. Build Ethernet drivers individually for each target. After all the Ethernet cards/carts are different enough to ask for customized drivers. Building the drivers individually opens the option to use .ifdef's to customize them. II. Removed Ethernet driver I/O base. So far the base address of the Ethernet chip was a general property of all Ethernet drivers. It served two purposes: 1. Allowing to use a single Ethernet driver for a certain Ethernet chip, no matter what machine was connected to the chip. 2. Allowing use an Ethernet card in all Apple II slots. However, we now use customized Ethernet drivers for the individual machines so 1.) isn't relevant anymore. In fact one wants to omit the overhead of a runtime-adjustable base address where it isn't needed. So only the Apple II slots are left. But this should rather be a driver-internal approach then. We should just hand the driver the slot number the user wants to use and have the driver do its thing. III. With per-target Ethernet drivers we can have per-target MAC addresses. IV. Added support for RR-Net MK3 unique MAC addresses. The RR-Net MK3 can be operated in two modes: - In cartrigde mode it has a startup-ROM that sets the CS8900A MAC address to the unique MAC address. - In clockport mode the driver has to read the two lowest MAC address bytes from the EEPROM and combine them with 28:CD:4C:FF. See http://wiki.icomp.de/wiki/RR-Net#Detecting_MK3 for details. The driver first checks if the current CS8900A MAC address starts with 28:CD:4C:FF. If it does, it overwrites its built in default MAC address with the CS8900A MAC address. If the CS8900A MAC address didn't start with 28:CD:4C:FF, it checks if there are two valid MAC address bytes in the EEPROM. If they are there, it overwrites its built in default MAC address with a combination of 28:CD:4C:FF and those two bytes. V. Added support for the upcoming 'Dracarys' Ethernet PBI for the ATARI. See http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/ for details on Dracarys. So far there was only one Ethernet solution for the ATARI. Therefore the relevant driver was loaded statically. With now having two solutions we have to load the corresponding driver dynamically (like on the other machines). Fortunately this doesn't mean significant additional overhead as there are several mouse drivers for the ATARI asking for dynamic mouse driver loading. Therefore the dynamic driver loading infrastructure was linked already. Another aspect of more than one Ethernet solution is that the Ethernet config program becomes necessary on the ATARI to select the correct driver. Although that program is pretty simple and therefore rather small it means that now only one "major" program fits on a 130kB disk. So we need now 5(!) 130kB disk images instead 3 so far.
2019-05-08 14:46:47 +00:00
ETHERNET_SOURCEFILES = cs8900a.S lan91c96.S w5100.S
There's no point in pulling in cfs-posix-dir.c if the POSIX functions it depends on are dummies anyway.
2010-10-23 08:17:45 +00:00
CONTIKI_TARGET_SOURCEFILES += pfs.S
Starting with the cc65-snapshot-2.11.9.20080316 the Apple2 C-library supports placing code in the Apple2 Language Card by choosing the code segment 'HIGHCODE'. By default the memory area 0xD400 - 0xE000 is used for HIGHCODE. If the application doesn't need the ProDOS 8 QUIT code then the memory area used for HIGHCODE may be extended to 0xD000 - 0xE000. Contiki now leverages that feature to place process.o, etimer.o and uip_arp.o in HIGHCODE. These files were carefully chosen as: - they are necessary for all Ethernet apps - their size doesn't depend on configuration macros - they fill the available space nicely (with a little reserve for changes in the source or the compiler)
2008-03-24 22:49:00 +00:00
cc65 2.13. comes with secondary linker configs. The 'apple2enh-reboot.cfg' is more or less what was previously engineered as part of Contiki for the Apple2 - now moved into the cc65 distro.
2009-10-18 10:06:44 +00:00
CONTIKI_CPU = $(CONTIKI)/cpu/6502
include $(CONTIKI_CPU)/Makefile.6502
Moved from last cc65 release (2.13.3) to recent cc65 snapshot (2.13.9). Relevant cc65 changes... General: - The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-) - The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-( Apple2: - The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config. Atari: - The builtin linker config allows to override the start addr so there no more need for a custom linker config. - The C library comes with POSIX directory access. So there's no more need for for a custom coding. CBM: - The C library comes with POSIX directory access. So there's no more need for for a custom coding.
2013-02-14 14:42:43 +00:00
LDFLAGS += -D __HIMEM__=0xBF00
Finetuned Language Card usage. Both the source code and the cc65 compiler have changed. So it made sense to review which object files are to be compiled for placement in the Language Card.
2013-03-06 13:57:24 +00:00
LC_SOURCEFILES = process.c tcpip.c
Moved from last cc65 release (2.13.3) to recent cc65 snapshot (2.13.9). Relevant cc65 changes... General: - The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-) - The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-( Apple2: - The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config. Atari: - The builtin linker config allows to override the start addr so there no more need for a custom linker config. - The C library comes with POSIX directory access. So there's no more need for for a custom coding. CBM: - The C library comes with POSIX directory access. So there's no more need for for a custom coding.
2013-02-14 14:42:43 +00:00
Up to now *all* Contiki apps for the Apple2 were built for maximal RAM - which means that they can't return to OS level but must reboot on exit. However many apps can get along well with 1kB less memory - which allows them to exit to the OS. Therefore now the default is 1kB less memory - and apps actually needing maximal RAM can get it by adding WITH_REBOOT to their DEFINES.
2010-09-08 22:50:56 +00:00
ifeq ($(findstring WITH_REBOOT,$(DEFINES)),WITH_REBOOT)
Moved from last cc65 release (2.13.3) to recent cc65 snapshot (2.13.9). Relevant cc65 changes... General: - The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-) - The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-( Apple2: - The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config. Atari: - The builtin linker config allows to override the start addr so there no more need for a custom linker config. - The C library comes with POSIX directory access. So there's no more need for for a custom coding. CBM: - The C library comes with POSIX directory access. So there's no more need for for a custom coding.
2013-02-14 14:42:43 +00:00
LDFLAGS += -D __LCADDR__=0xD000 -D __LCSIZE__=0x1000
Rearrange Apple II language card usage. The code of etimer.o has become to large to fit into $D000-$D400. So other object file have been chosen.
2015-06-28 20:12:44 +00:00
LC_SOURCEFILES += autostart.c timer.c uip_arch.c uiplib.c
Up to now *all* Contiki apps for the Apple2 were built for maximal RAM - which means that they can't return to OS level but must reboot on exit. However many apps can get along well with 1kB less memory - which allows them to exit to the OS. Therefore now the default is 1kB less memory - and apps actually needing maximal RAM can get it by adding WITH_REBOOT to their DEFINES.
2010-09-08 22:50:56 +00:00
endif
The feature set of gnumake is really frightening: This time I discovered 'target-specific variable values'...
2008-05-26 11:26:57 +00:00
# Set a target-specific variable value
Moved from last cc65 release (2.13.3) to recent cc65 snapshot (2.13.9). Relevant cc65 changes... General: - The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-) - The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-( Apple2: - The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config. Atari: - The builtin linker config allows to override the start addr so there no more need for a custom linker config. - The C library comes with POSIX directory access. So there's no more need for for a custom coding. CBM: - The C library comes with POSIX directory access. So there's no more need for for a custom coding.
2013-02-14 14:42:43 +00:00
${addprefix $(OBJECTDIR)/,${call oname, $(LC_SOURCEFILES)}}: CFLAGS += --code-name LC
Starting with the cc65-snapshot-2.11.9.20080316 the Apple2 C-library supports placing code in the Apple2 Language Card by choosing the code segment 'HIGHCODE'. By default the memory area 0xD400 - 0xE000 is used for HIGHCODE. If the application doesn't need the ProDOS 8 QUIT code then the memory area used for HIGHCODE may be extended to 0xD000 - 0xE000. Contiki now leverages that feature to place process.o, etimer.o and uip_arp.o in HIGHCODE. These files were carefully chosen as: - they are necessary for all Ethernet apps - their size doesn't depend on configuration macros - they fill the available space nicely (with a little reserve for changes in the source or the compiler)
2008-03-24 22:49:00 +00:00
Added make target 'disk' for creating a .dsk disk image using AppleCommander.
2008-05-22 22:21:43 +00:00
ifeq ($(MAKECMDGOALS),disk)
ifndef AC
${error AC not defined! You must specify where the AppleCommander jar resides}
endif
endif
disk: all
Now that we have at least two examples working on the cc65 targets it is preferable to not name the program files all 'contiki'.
2010-01-31 09:34:12 +00:00
cp $(CONTIKI)/tools/$(TARGET)/prodos.dsk contiki.dsk
Adjusted to cc65 2.17 which generates AppleSingle files.
2018-03-08 16:23:43 +00:00
java -jar $(AC) -p contiki.dsk contiki.system sys < $(CC65_TARGET_DIR)/util/loader.system
java -jar $(AC) -as contiki.dsk contiki < $(CONTIKI_PROJECT).$(TARGET)
Added SLIP support to retro platforms. The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet. Some notes: - The Ethernet configuration was simplified in order to allow share it with SLIP. - The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer. - As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent. On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically. On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
2017-02-15 22:43:28 +00:00
ifdef SLIP
Adjusted to cc65 2.17 which generates AppleSingle files.
2018-03-08 16:23:43 +00:00
java -jar $(AC) -p contiki.dsk contiki.cfg bin 0 < $(CONTIKI)/tools/6502/sample.cfg
Added SLIP support to retro platforms. The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet. Some notes: - The Ethernet configuration was simplified in order to allow share it with SLIP. - The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer. - As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent. On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically. On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
2017-02-15 22:43:28 +00:00
else
Adjusted to cc65 2.17 which generates AppleSingle files.
2018-03-08 16:23:43 +00:00
java -jar $(AC) -p contiki.dsk contiki.cfg bin 0 < $(CONTIKI)/tools/$(TARGET)/sample.cfg
Updated several aspects regarding Ethernet drivers. I. Build Ethernet drivers individually for each target. After all the Ethernet cards/carts are different enough to ask for customized drivers. Building the drivers individually opens the option to use .ifdef's to customize them. II. Removed Ethernet driver I/O base. So far the base address of the Ethernet chip was a general property of all Ethernet drivers. It served two purposes: 1. Allowing to use a single Ethernet driver for a certain Ethernet chip, no matter what machine was connected to the chip. 2. Allowing use an Ethernet card in all Apple II slots. However, we now use customized Ethernet drivers for the individual machines so 1.) isn't relevant anymore. In fact one wants to omit the overhead of a runtime-adjustable base address where it isn't needed. So only the Apple II slots are left. But this should rather be a driver-internal approach then. We should just hand the driver the slot number the user wants to use and have the driver do its thing. III. With per-target Ethernet drivers we can have per-target MAC addresses. IV. Added support for RR-Net MK3 unique MAC addresses. The RR-Net MK3 can be operated in two modes: - In cartrigde mode it has a startup-ROM that sets the CS8900A MAC address to the unique MAC address. - In clockport mode the driver has to read the two lowest MAC address bytes from the EEPROM and combine them with 28:CD:4C:FF. See http://wiki.icomp.de/wiki/RR-Net#Detecting_MK3 for details. The driver first checks if the current CS8900A MAC address starts with 28:CD:4C:FF. If it does, it overwrites its built in default MAC address with the CS8900A MAC address. If the CS8900A MAC address didn't start with 28:CD:4C:FF, it checks if there are two valid MAC address bytes in the EEPROM. If they are there, it overwrites its built in default MAC address with a combination of 28:CD:4C:FF and those two bytes. V. Added support for the upcoming 'Dracarys' Ethernet PBI for the ATARI. See http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/ for details on Dracarys. So far there was only one Ethernet solution for the ATARI. Therefore the relevant driver was loaded statically. With now having two solutions we have to load the corresponding driver dynamically (like on the other machines). Fortunately this doesn't mean significant additional overhead as there are several mouse drivers for the ATARI asking for dynamic mouse driver loading. Therefore the dynamic driver loading infrastructure was linked already. Another aspect of more than one Ethernet solution is that the Ethernet config program becomes necessary on the ATARI to select the correct driver. Although that program is pretty simple and therefore rather small it means that now only one "major" program fits on a 130kB disk. So we need now 5(!) 130kB disk images instead 3 so far.
2019-05-08 14:46:47 +00:00
java -jar $(AC) -p contiki.dsk cs8900a.eth rel 0 < cs8900a.$(TARGET)
Added make target 'disk' for creating a .dsk disk image using AppleCommander.
2008-05-22 22:21:43 +00:00
endif
ifeq ($(HTTPD-CFS),1)
Adjusted to cc65 2.17 which generates AppleSingle files.
2018-03-08 16:23:43 +00:00
java -jar $(AC) -p contiki.dsk index.htm bin 0 < httpd-cfs/index.htm
java -jar $(AC) -p contiki.dsk backgrnd.gif bin 0 < httpd-cfs/backgrnd.gif
java -jar $(AC) -p contiki.dsk contiki.gif bin 0 < httpd-cfs/contiki.gif
java -jar $(AC) -p contiki.dsk notfound.htm bin 0 < httpd-cfs/notfound.htm
Added make target 'disk' for creating a .dsk disk image using AppleCommander.
2008-05-22 22:21:43 +00:00
endif
Reference in New Issue Copy Permalink